POLITEHNICA UNIVERSITY OF BUCHAREST

COMPUTER SCIENCE DEPARTMENT

GRADUATION PROJECT

Vehicle Ad-Hoc Networks

Dedicated Short-Range Communication Protocol

Scientific coordinators :

Prof. Valentin Cristea , Ph.D. , Politehnica University of Bucharest

Assistant Victor Gradinescu B.Sc. , Politehnica University of Bucharest

Author :

Cristian Aurelian Petroaca

June 2007

Overview

The present Thesis is structured in six chapters. This is an overview of the contents of these
chapters.
The first chapter is the Introduction where the objectives and the motivation of the thesis are
presented .
The second chapter deals with the theoretical aspect of Vehicular Networks and some related
work in the field.
The third chapter Simulation Environment presents the practical implementations of the
project .
The fourth chapter represents the testing and the results of the implementation .
The fifth chapter are the conclusions that can be drawn from the previous chapter and some
ideas for future work.
The sixth chapter are the references used during the paper.
The seventh chapter represents the annex containing some important code from the application.

Table of contents
1. Introduction ......................................................................................................................................... 4
2. Vehicular Networks ............................................................................................................................ 6
2.1. DSRC Protocol Overview ............................................................................................................ 6
2.2 Radio Propagation Models Overview ........................................................................................... 7
2.3 Background and Related Work ..................................................................................................... 9
3. Simulation Environment ................................................................................................................... 14
3.1 TrafficView Simulator Overview ............................................................................................... 14
3.2. DSRC Protocol Implementation ................................................................................................ 16
3.2.1 Physical Layer...................................................................................................................... 17
3.2.2 MAC Layer .......................................................................................................................... 20
3.2.3 Application Layer................................................................................................................. 25
3.3 Radio Propagation Models Implementation................................................................................ 32
3.3.1 Two Ray Ground.................................................................................................................. 32
3.3.2 Shadowing............................................................................................................................ 33
3.3.3 Ricean fading ....................................................................................................................... 34
3.4 Statistical Information Implementation....................................................................................... 36
3.5 Other Implementation Choices ................................................................................................... 38
4. Simulation Results ............................................................................................................................ 40
4.1 Simulation Setup ......................................................................................................................... 40
4.2 CSMA/CA protocol enhancement .............................................................................................. 40
4.3 DSRC Communication channels................................................................................................. 43
4.4 DSRC physical parameters ......................................................................................................... 45
4.5 DSRC Applications Performance ............................................................................................... 47
4.6 Radio Propagation Models Performance .................................................................................... 51
5. Conclusions and Future Work........................................................................................................... 57
6. References ......................................................................................................................................... 59
7. Annex ................................................................................................................................................ 61

1. Introduction
Dedicated Short-Range Communications (DSRC) is a promising wireless technology which
operates in the 5.9 GHz range with 75 MHz of spectrum . It is a wireless protocol standard still under
development which is designed to support vehicle-to-vehicle and vehicle-to-infrastructure
communication . Its primary purpose is to support critical safety applications which will reduce the
number of accidents on the road and as a result will reduce the number of lives lost and its secondary
purpose is to improve traffic flow , although aside from these two , private services will also be
permitted.
DSRC will have six service channels and one control channel .The control channel will be
used for the transmission and reception of safety of life messages and also service advertisements
and the service channels will be used for other non-safety-critical messages.
This standard is based on the IEEE 802.11a technology and as a result the physical layer
follows the same frame structure , 64 sub-carrier OFDM based modulation scheme but it has a 10
MHz channel bandwidth and this changes the maximum data rate , timing parameters and frequency
parameters. At the MAC layer , the DSRC standard uses a 7 channel band with a distinction between
safety and non safety messages and so it implements a message priority scheduler . Aside from these
differences DSRC follows the 802.11a standard.

Project Objectives and Motivation

TrafficViewSimulator is a data dissemination system which simulates the environment of a

vehicular wireless network. It simulates the mobility of vehicles and the wireless communication
between them .
The main objective of this thesis is to implement the DSRC communication protocol in
TrafficViewSimulator . This will require the implementation of all the layers in the protocol stack :
Physical , Data Link ( MAC ) and Application layers.
The second objective of this project is to implement on top of the DSRC protocol , a group of
safety applications such as Forward Collision Warning , Lane Change Warning , Curve Speed
Warning and scenarios that would create the environment for them appropriately .

Furthermore , the TrafficViewSimulator needs to have implemented additional radio

propagation models , such as Shadowing and Ricean and Rayleigh propagation models.
The motivation behind these objectives is to complete the TrafficViewSimulator by
encapsulating the DSRC protocol and further to simulate Safety Applications in order to study their
feasibility and efficiency . The simulation of this type of applications gives us a mode detailed
perspective on the practical aspect of DSRC .Also , the motivation behind the implementation of the
different propagation models is to have a simulation which is as close to the real propagation of radio
waves as possible.

2. Vehicular Networks

2.1. DSRC Protocol Overview

Dedicated Short-Range Communications Protocol is a multi-channel wireless protocol , still
under development , that is based on the IEEE 802.11a Physical Layer and the IEEE 802.11 MAC
Layer . It operates over a 75 MHz licensed spectrum in the 5.9 GHz band allocated by the FCC for the
support of low latency vehicle-to-vehicle and vehicle-to- infrastructure communications.
The motivation behind the development of DSRC is based mainly on the need for a more
tightly controlled spectrum for maximized reliability. The use of hand- held and hands- free devices that
occupy the 2.4 and 5 GHz bands along with the increase of WiFi could cause intolerable and
uncontrollable levels of interference that would significantly decrease the reliability and effectiveness
of vehicular safety applications. But even with a licensed band , some issues arise , such as fair access
to all applications , including priority scheduling of traffic between different application classes (
safety over non-safety).Unlike 802.11 , multi-channel coordination is a fundamental capability of
DSRC.
DSRC is similar to 802.11a , but there are still some major differences :

Operating Frequency Band : DSRC operates in a 75 MHz spectrum in a 5.9 GHz dedicated
band , but IEEE 802.11a operates only on the unlicensed portions of the 5 GHz band.

Application Environment : DSRC is supposed to work in an outdoor high-speed environment

as opposed to 802.11a which is designed for indoor WLAN. This brings new problems for wireless
channel propagation considering the multi-path delay and Doppler effects caused by high speed.

MAC Layer :The DSRC band is divided into 7 channels , one control channel to support
safety applications and 6 service channels to support non-safety applications. Prioritizing safety
messages over non-safety ones is one of the DSRC MAC layer capabilities , this being related to
multi-channel coordination. Aside from this , the MAC layer follows the original 802.11 MAC.

Physical Layer : The bandwidth of each DSRC channel is 10 MHz , as opposed to 20 MHz
channel in 802.11a . This has a direct impact on the maximum data rate it can support ( 27 Mbps ) , as

well as timing parameters and frequency parameters. Also the transmit power limit is different than
that of the 802.11a protocol. Aside from these differences , it follows the same frame structure , 64sub-carrier OFDM based modulation scheme .

5.860

5.870

5.880

Control Channel
5.900
5.890

Service Channels

Figure 1

5.910

5.920

Service Channels

DSRC channel arrangement

2.2 Radio Propagation Models Overview

The characteristics of radio channels are much more complicated to analyze than those of
wired channels. These characteristics may change rapidly and randomly . There are large differences
between simple paths with line of sight and those which have obstacles like buildings or elevations
between the sender and the receiver. The basic phenomena in wireless mobile communication can be
summarized to : reflection , diffraction and scattering. These phenomena are created due to static
obstacles(buildings , trees) , moving obstacles ( other vehicles ) , interferences ( other
communications ) , multi-path propagation and the speed effect.
There are two types of propagation models : large scale and small scale. The large scale
propagation models propose that a radio wave has to travel a larger growing distance between the
sender and the receiver while small scale models ( fading models ) calculate the signal strength
depending on small movements . Because of multi-path propagation of radio waves , movements of
the receiver can have large effects on the received signal .

The following four propagation models are the most used models in wireless ad- hoc network
simulators ( such as ns-2 , QualNet ) :

Free Space Model : The free space propagation model assumes the ideal propagation
condition that there is only one clear line-of-sight path between the transmitter and receiver. H. T. Friis
presented the equation to calculate the received signal power in free space at distance from the
transmitter. The received power is only dependent on the transmitted power Pt , the antennas Gains
and on the distance from the sender to the receiver.

Two Ray Ground Model : A single line-of-sight path between two mobile nodes is seldom
the only means of propagation. The two-ray ground reflection model considers both the direct path and
a ground reflection path. It is shown that this model gives more accurate prediction at a long distance
than the free space model. The received energy is the sum of the direct line of sight path and the path
including one reflection on the ground between the sender and the receiver.

Ricean and Rayleigh fading : these two models are fading models and they describe the timecorrelation of the received signal power.Fading occurs because of the multi-path of the radio waves.
Rayleigh fading occurs when there are multiple indirect paths between the sender and the receiver and
Ricean fading occurs when there is only one dominant line of sight path and multiple indirect signals.
In the case of Rayleigh fading the mobile antenna receives a large number, say N, reflected and
scattered waves. Because of wave cancellation effects, the instantaneous received power seen by a
moving antennna becomes a random variable, dependent on the location of the antenna

Shadowing Model : in this model the received power at certain distance is a random variable
due to multi-path propagation effects, which is also known as fading effects.It is assumed that the
average received signal power decreases logarithmically with distance and a Gaussian random variable
is added to this path loss to account for influences from the environment.

In the study of radio wave propagation in mobile networks we must also include the Doppler
shift of the frequency due to the speed of the vehicle.In the Doppler shift the wavelength of the radio
wave changes with the speed of the source according to the formula : =1-(Vsource * T ) .

2.3 Background and Related Work

Since it is a technology under development , DSRC is still being researched by both
universities and major car manufacturers , and most of this research is being directed at building
vehicular simulators . These simulators provide useful data for designing reliable and efficient safety
applications such as collision avoidance , traffic flow control or traveler information/support.

A team of researchers from Daimler-Chrysler released a paper in 2006 in which they talked
about the architecture implementation of IEEE 802.11 in NS-2 and they also presented their
modifications to the MAC and Physical layers of this architecture in order to make it more accurate for
DSRC simulations. The initial 802.11 architecture consists of 3 layer modules , the Physical ,
MAC802.11 and UpperLayer (Application) , which can communicate with each other . The Physical
layer module also communicates with a propagation model module , a mobile node module and a
Wireless Channel module .The current design doesnt work well with wireless communication
influenced by roadway , terrain , interference and also it does not work well under stressful conditions
such as pervasive broadcast activities by many vehicles ( such as an intersection ). In order for the
design to accommodate these changes , they introduced a cumulative NoiseMonitor at the Physical
Layer and a new signaling device between Physical and MAC , thus every time the Physical layer
detects a high level of interference/noise it signals the MAC layer to enter a channel busy state. Also ,
there is a more correct distribution of functions at the Physical and MAC according to the 802.11
standard. They tested both architectures with identical simulation parameters and concluded that the
default NS-2 design doesnt add up multiple and overlapping interference signals , thus it produces
results that are too optimistic. The new design correctly reflects the situations in which a frame is lost
or when a collision occurs.

Another research done by UCLA Computer Science Department emphasizes the Effects of
Wireless Physical Layer modeling to mobile networks. They describe the primary factors that are
relevant in modeling the physical layer . Firstly they state that the length of signal preamble and
header for the physical layer has an important effect on the performance of the higher layer protocols.
Secondly , interference computation and signal reception ; there are two types : the SNR threshold
based model which uses the SNR ( Signal to Noise Ratio) value directly by comparing it to with a

SNR threshold and accepts only signals whose SNR have been above this value ; the BER based
model probabilistically decides whether or not each frame is received successfully based on the frame
length and the Bit Error Rate. The last factor is fading and path loss . Fading is a variation of signal
power at receivers caused by node mobility . Commonly used fading models are Rayleigh and Ricean
distributions .Path loss defines the average signal power loss of a path on the terrain .They discovered
that the length of the preamble dramatically affects some ad hoc routing protocols such as AODV and
also that the simulation performs better with the free space propagation model and worse with the two
ray model but the latter is more realistic.

A team from General Motors R&D department together with a group from HRL Laboratories ,
Malibu worked on a performance evaluation of Cooperative Collision Warning applications which run
on DSRC .They simulated the following scenario : a simple 8- lane straight freeway stretch of length 1
mile with 4 lanes in each direction and no entries/exits . On this scenario , the vehicles were running
the Forward Collision Warning(FCW) application .In FCW each vehicle has a GPS device in addition
to a wireless device running DSRC . Each vehicle broadcasts periodically to its neighbors a message
containing its location , speed , control settings so that the neighbors could use this information to
calculate the probability of colliding with that vehicle. In FCW the only messages of interest are those
coming from the vehicles in front of the car.
In their simulation all vehicles have pin-point precision GPS devices , DSRC wireless devices
and at the start of the run all the vehicles on the freeway start transmitting fixed size messages (100 B)
in UDP broadcast packets with a additional random dithering and continue transmitting until the end
of the simulation.
The Performance metrics :
-

packet inter-reception time (IRT) : the time elapsed between 2 successive successful
reception events at the home-vehicle.

cumulative number of packet receptions at the home-vehicle from a given

transmitter: the cumulative number of packets successfully received plotted against
simulation time.

packet success probability : the percentage of packets successfully received by a

vehicle from a transmitter during the simulation run.

per-packet latency for packets sent by a specific transmitter

The simulation results presented the following conclusions : in a high-density scenario a host-

10

vehicle would have approx. 118 to 230 vehicles within its radio range , thus a total of 348 vehicles
trying to access the channel which confirms that it overloads the road capacity .; in a low-density
scenario the IRT and PSP performance metrics are higher as expected , but the performance gap is not
that high , so high density performance could be improved with the aid of broadcast enhancement
techniques such as : Application Broadcast Rate Adaptation and Transmission Range Adaptation .
In 2004 , a group of researchers from University of California , Berkeley and another from
California PATH , Richmond studied vehicle-to-vehicle safety messaging using DSRC. Their paper
explores the feasibility of sending safety messages from vehicle to vehicle in the DSRC control
channel with high reliability and low delay and for this purpose they propose a single hop service to
broadcast messages while meeting the Quality of Service requirements in vehicular ad-hoc networks.
Firstly they propose that at different speeds the interval between two messages should vary .
For example at 90 mph a vehicle moves 2 meters in 50 msec , thus messages repeating at faster that
every 50 msec dont bring much new information. This is supposed to decrease the number of
messages on the channel and the collisions. Secondly , they propose that if the cars are closer together
( in a traffic jam) then the radio range of the transmitted message should be shorter , also for the
decongestion of the medium.
In unicast communication reliability is enhanced by policies based on receiver feedback , such
as RTS/CTS ,TCP but in mobile wireless networks where the nodes of the network change very fast
this kind of reliability is not very feasible . Therefore , their protocol repeats every message without
acknowledgement in combination with CSMA and its variants . Their protocol uses two schemes to
reduce the Probability of failure , repetition and carrier sensing. Their protocol is a MAC extension
layer and would lie between the Logical Link Control Layer and the Standard MAC Layer.
According to their simulation results , the range of data traffic that might be offered by safety
application designers is not entirely feasible ( the Probability of Failure becomes too high 1/10 or
higher at certain values) . Their second finding is that some offered traffic levels are feasible only if
network designers and safety application designers work together.

At the 2006 edition of VANET , a team from University of Illinois together with a group from
Toyota Technical Center presented a paper in which they discussed a method for efficient data
exchange between vehicles running multiple safety applications.

11

In their thesis they have identified several safety applications which will provide the greatest
benefits:
1. Traffic Signal Violation Warning
2. Curve Speed Warning
3. Emergency Electronic Brake Lights
4. Pre-Crash Warning
5. Cooperative Forward Collision Warning
6. Left Turn Assistant
7. Lane Chance Warning
8. Stop Sign Movement Assistance
The communication frequency of these ranges from 1-50 Hz , the size of the packet 200-500
Bytes and the maximum communication range 50-300 meters. There are over 70 vehicle Data
Elements which respond to these applications ( heading , acceleration , headlight status , brake status) .
Of these data sets 30 are common to all applications , the rest are specific for different ones.
Their basic idea is the Message Dispatcher , which is responsible to coordinate all the data
exchange , doing so by serving as an interface between the applications and the communication stack.
Safety applications will send data elements to the MD and it will summarize them across applications
and create a single packet to be transmitted.
They tested on a real wireless DSRC device running on a Linux based machine , with a
commercial GPS .Their results concluded that the use of the MD on a maximum DSRC channel of 27
Mbps the reduction of the channel loading is relevant.

In the research community there are many network simulators but only two of them have been
implementing a module for vehicular networks simulation : GloMoSim and NS-2 simlators.

GloMoSim is a scalable simulation library for wireless network systems built using the
PARSEC simulation environment . GloMoSim also supports two different node mobility models.
Nodes can move according to a model that is generally referred to as the random waypoint model .
A node chooses a random destination within the simulated terrain and moves to that location based on
the speed specified in the configuration file. After reaching its destination, the node pauses for a
duration that is also specified in the configuration file. The other mobility model in GloMoSim is
referred to as the random drunken model. A node periodically moves to a position chosen randomly

12

from its immediate neighboring positions. The frequency of the change in node position is based on a
parameter specified in the configuration file.
In contrast to existing network simulators such as OPNET and NS, GloMoSim has been
designed and built with the primary goal of simulating very large network models that can scale upto a
million nodes using parallel simulation to significantly reduce execution times of the simulation
model..As most network systems adopt a layered architecture, GloMoSim is being designed using a
layered approach similar to the OSI seven layer network architecture. Simple APIs are defined
between different simulation layers.This allows the rapid integration of models developed at different
layers by different people. Actual operational code can also be easily integrated into GloMoSim with
this layered design, which is ideal for a simulation model as it has already been validated in real life
and no abstraction is introduced. For example, a TCP model was implemented in GloMoSim by
extracting actual code from the FreeBSD operating system. This also reduces the amount of coding
required to develop the model.

NS-2 is an open-source simulation tool that runs on Linux. It is a discreet event simulator
targeted at networking research and provides substantial support for simulation of routing, multicast
protocols and IP protocols, such as UDP, TCP, RTP and SRM over wired and wireless (local and
satellite) networks. It has many advantages that make it a useful tool, such as support for multiple
protocols and the capability of graphically detailing network traffic. Additionally, NS2 supports
several algorithms in routing and queuing. LAN routing and broadcasts are part of routing algorithms.
Queuing algorithms include fair queuing, deficit round-robin and FIFO.
NS2 started as a variant of the REAL network simulator in 1989 (see Resources). REAL is a
network simulator originally intended for studying the dynamic behavior of flow and congestion
control schemes in packet-switched data networks.
Currently NS2 development by VINT group is supported through Defense Advanced Research
Projects Agency (DARPA) with SAMAN and through NSF with CONSER, both in collaboration with
other researchers including ACIRI (see Resources). NS2 is available on several platforms such as
FreeBSD, Linux, SunOS and Solaris. NS2 also builds and runs under Windows.

13

3. Simulation Environment

3.1 TrafficView Simulator Overview

The VANET Simulator in which the DSRC Protocol will be implemented is
TrafficViewSimulator . This simulator is a discrete event simulator meaning that the simulation time
advances with a fixed time resolution after executing the simulator code for the current moment of
time.
The VANET application consists of an event queue which can hold 3 types of events : Send ,
Receive and GPS. A Send event for a specified node triggers the calling of the nodes procedure
responsible for preparing a message. That send event is then inserted into the Event Queue . The
Engine of the simulator checks this Event Queue at a regular fixed amount of time , and for any Send
Event found it creates one Receive Event ( if the Send Event is Unicast ) or several Receive Events
for everyone of the nodes which are in the wireless range of the sender. When a Receive Event is
created first the Engine checks to see if there is another Receive Event corresponding to the same
Receiver for the current simulation time, and if it is , it adds this Receive Event to the receivers
event list .This makes it easier when the Receiver simulates the receive procedure of an Event , it has
to check its Receive Event list and chooses one according to a receive power threshold and
interference level. The GPS Event is scheduled at a regular time interval for each node thus accurately
simulating the way a real VANET application collects GPS data periodically.

14

.
Figure 2

The architecture of the simulator that emulates a VANET application

The mobility module updates periodically the position of each vehicle-node according to the
vehicular mobility model. This model takes into consideration vehicle interactions , traffic rules and
various driver behavior.
The network model takes into consideration the position and the wireless range of the vehicles
, medium access and the propagation model of radio waves according to the Two Ray Ground model.
The Simulator delivers a message to all the receiving nodes in the wireless range using an
optimized local search thru the nodes. This is possible due to indexing the map point locations of the
nodes with a PeanoKey mechanism which scans the geographical area around a node.
For a more accurate network model , the nodes protocol stack is taken into account and thus
the simulator can have the packet encapsulation process by adding the corresponding headers to the
message . The transport layer is UDP , and the IP network layer is replaced by a geographical routing
and addressing scheme. The MAC layer is the one in 802.11b.

15

3.2. DSRC Protocol Implementation

The DSRC Protocol is implemented as an OSI stack with the Physical , MAC , Application
Layers and it relies heavily on the 802.11 protocol stack and the 802.11 implementation details , but it
also focuses on the differences which it has when comparing with 802.11 , especially the differences at
the Physical and MAC Layers.

Application

MAC802.11
Indicate(busy/idle)
Noise Monitor

Send/Recv Packet
Propagation model

Physical

RecvHandler

SendHandler

EventQueue
Figure 3 The new DSRC modules ( in Blue )

In Figure 3 , you can see the DSRC OSI Stack communicating with the old elements in the
Simulator. The Physical layer communicates with the send routine which gets the packet , creates a
new Send Event and adds it to the Event Queue and with the receive routine which gets the Receive
Event from Event Queue and sends the message to the Physical Layer. The Physical Layer also
communicates with the Propagation modules and Noise Monitor module. The MAC Layer sends and

16

receives packets from/to Physical but also checks the status of the channel thru Physical . The
application Layer receives and sends packets from/to MAC .
All 3 OSI Layer classes are contained in the CarRunningDSRC class which extends the
CarRunningVITP class . The NoiseMonitor class is contained in the Physical Layer class.
The architecture above is based on the architecture described in [1].
The following sections will explain in greater detail all of the comprising modules of the
DSRC Protocol.

3.2.1 Physical Layer

The Physical layer of DSRC is being modeled after the 802.11a physical layer but it has some
major differences such as the bandwidth of each channel is 10 MHz as opposed to 20 MHz in 802.11
and this has an impact on the maximum data rate DSRC can support ( 27 Mbps ) , timing parameters (
guard interval of 1.6 sec ) and frequency parameters.
Also DSRC has a maximum transmission power limit depending on the channel it transmits on
, as in the following description :
Ch172 ( 5.860 Public Safety/HALL ) 33 dBm
Ch174 ( 5.870 Public Safety/Private) 33 dBm
Ch176 ( 5.880 Public Safety/Private) 33 dBm
Ch178 ( 5.890 Control Channel ) - 44.8 dBm
Ch180 ( 5.900 Public Safety/Private) 23 dBm
Ch182 ( 5.910 Public Safety/Private) 23 dBm
Ch184 ( 5.920 Public Safety/Intersections) 40 dBm

Besides these differences the DSRC Physical Layer follows the specifications of the 802.11
Physical.

The 802.11 physical layer (PHY) is the interface between the MAC and the wireless media
where frames are transmitted and received. The PHY provides three functions. First, the PHY provides
an interface to exchange frames with the upper MAC layer for transmission and reception of data.
Secondly, the PHY uses signal carrier and spread spectrum modulation to transmit data frames over

17

the media. Thirdly, the PHY provides a carrier sense indication back to the MAC to verify activity on
the media.

In the simulator the Physical Layer is implemented in the WirelessPhy class and the
NoiseMonitor class.
The NoiseMonitor class is conceived to store the cumulative interference and noise level which
reach the mobile station ( PHY ) during a frame transmission/reception time.It contains a variable in
which the interference and noise is being added up by WirelessPhy . It also contains a thermal noise
variable which is the initial value stored in the interference and noise level variable which represents
the environmental noise which a station picks up.

The WirelessPhy class represents the Physical Layer and it contains :

a NoiseMonitor object which as explained before keeps track of all the interference
and noise during a frame time .

a state machine ( int variable ) which keeps track of the state the Physical Layer is
in , Idle ( no activity ) , Txing ( transmitting a frame ) , Rxing ( receiving a frame ).

a SINR variable which is calculated every time the Physical layer receives signal
and is used by the MAC to calculate the Packet Error Rate .The SINR value is the
ratio of the received power of the signal to the sum of the other signals which arrive
in the same frame time.

a Carrier Sense Threshold ; when a signal arrives if it is under this threshold then it
cannot be detected by the radio , a Receive Threshold , a Collision Threshold.

The functionality of the WirelessPhy :

WirelessPhy.recvFromChannel() : in the case of a ReceiveEvent , the physical layer of the

wireless station calls this function . The function takes as argument a list of ReceiveEvents which are
all the signals which this station receives in a time frame.First it checks the stateMachine to see if it is
Idle and if it is not then the station cannot receive the frame and it drops it.If the stateMachine is Idle
then the layer takes all the signals , calculates their received power according to the type of
propagation model , then finds out the one signal with the maximum received power which is above

18

the Carrier Sense Threshold .If such a signal doesnt exist , then none of the packets can be received ,
otherwise the stateMachine is set on Rxing , it adds the other signals as interference , then if the max
power frame is above the Receive Threshold ( it has enough power to decode the preamble and
physical header ) then the layer checks for collision possibility with other receivable signals ( it
compares the ratio of the max signal to the other signals with the Collision threshold ) and if there are
no collisions the it returns the ReceiveEvent with the max power.If a collision is detected then it drops
all the packets.If the max power frame is under the Receive Threshold then the packet is tagged as
corrupted and sent to Mac.
WirelessPhy.sendToChannel() : when it receives a frame from Mac it sets its stateMachine to
Txing and returns the frame.
WirelessPhy.refreshFrameTime(): if the current time of the simulation is bigger by one frame
time than the local current time then it means that all the actions performed in the last frame time are
gone and it has to reset its stateMachine to Idle and its interference and noise level to the original
thermal noise power.
The Physical Layer can use the standard Transmitter power value of 15 dBm or it can use the
DSRC Transmitter Power of 33 dBm.

The packet at the Physical level is simulated by the DsrcPacket class . It contains :

- the preamble as a 12 byte variable ( contains 12 symbols and enables the receiver to acquire
an incoming OFDM signal)
- the PCLP header as a 3 byte variable ( contains the fields : Rate , Reserved, Length , Parity ,
Tail , Service, PSDU , Pad Bits )
- the Mac Frame as a DsrcFrame class.

In conclusion , the WirelessPhy object fulfills the functions of a Physical layer , such as it
communicates with the Mac when transmitting or receiving a frame , it simulates the OFDM
modulation coding/decoding by analyzing the power of the frame , it keeps track of all the interference
and noise on the channel during a frame time and it signals MAC accordingly.

19

3.2.2 MAC Layer

The MAC Layer of DSRC relies on the 802.11 MAC layer and all its extensions but there is a
major difference between the two layers. Given the fact that DSRC band plan consists of seven
channels which include one control channel to support high-safety messages and six service channels
to support non-safety messages. Prioritizing safety over non-safety is the function incorporated by the
DSRC MAC.

The 802.11 MAC layer provides functionality to allow reliable data delivery for the upper
layers over the wireless PHY media. The data delivery itself is based on an asynchronous, best-effort,
connectionless delivery of MAC layer data. There is no guarantee that the frames will be delivered
successfully.

The 802.11 MAC provides a controlled access method to the shared wireless media called CarrierSense Multiple Access with Collision Avoidance (CSMA/CA). CSMA/CA is similar to the collision
detection access method deployed by 802.3 Ethernet LANs
The fundamental access method of 802.11 is Carrier Sense Multiple Access with Collision
Avoidance or CSMA/CA. CSMA/CA works by a "listen before talk scheme". This means that a
station wishing to transmit must first sense the radio channel to determine if another station is
transmitting.

If

the

medium

is

not

busy,

the

transmission

may

proceed.

The CSMA/CA protocol avoids collisions among stations sharing the medium by utilizing a random
backoff time if the stations physical or logical sensing mechanism indicates a busy medium. The
period of time immediately following a busy medium is the highest probability of collisions occurring,
especially

under

high

utilization.

The CSMA/CA scheme implements a minimum time gap between frames from a given user. Once a
frame has been sent from a given transmitting station, that station must wait until the time gap is up to
try to transmit again. Once the time has passed, the station selects a random amount of time (the
backoff interval) to wait before "listening" again to verify a clear channel on which to transmit. If the
channel is still busy, another backoff interval is selected that is less than the first. This process is
repeated until the waiting time approaches zero and the station is allowed to transmit. This type of
multiple access ensures judicious channel sharing while avoiding collisions.
20

In TrafficView , the CSMA/CA protocol is implemented in MAC with respect to the

interference and noise level in the Physical Layer . In more detail , every time the physical layer
processes a ReceiveEvent it adds the resulting interference to its local variable and if this interference
becomes higher than a fixed threshold or if the physical layer entered successfully the Rxing mode
then the MAC layer is signaled by changing its local variable ChannelState to Busy.When the MAC
layer wants to send a message it checks the ChannelState variable and if it is Busy then it schedules
the Send Event to be transmitted in backoff+1 frame times .
Also the MAC layer is responsible with the CRC checksum of every incoming frame . This
will be explained in the MAC functionality next.

The MAC80211 class contains :

- Channel State variable which can be set to Busy or Idle.

- RxState , TxState whixch can be set to RX_RECV , RX_IDLE or TX_TRSM , TX_IDLE.
- backoff timer set initially to 0.

The MAC Layer functionality:

MAC80211.recvFromPhysical(): receives the ReceiveEvent with the maximum received

power from physical which has also passed all the tests performed by physical.If the frame is tagged as
corrupted by physical then MAC checks the frames SINR value with the modulation specific SINR
Threshold and if it is lower than this threshold then it drops the frame . If not , the MAC performs the
Packet Error Rate calculations to see whether the whole frame body can be decoded.The PER is
calculated for every part of the packet ( the preamble , the phy header and the rest of the frame body )
as follows : for the given length of the part of the packet , and the SINR value at that moment , it
applies a complementary error function to the square root of the SINR * signal_spread/data_rate which
equals BER. Then it calculates Math.pow(1-BER,number_bits) . For the PCLP header of the frame the
data rate is 1 Mbps and for the rest is normal.It multiplies all of the results above and then returns its
complemetary ( 1-result ) .
The complementary error function is described by :

21

If the PER is above a given threshold then the frame is received ok and it changes its RXState
to RX_RECV and returns the message to the Application layer.

MAC80211.sendToPhysical() : checks the ChannelState and if it is not busy it sends the frame
to physical otherwise it increments the backoff timer by one and it reschedules the send event to that
time , otherwise it sets the backoff timer to 0 and sets the TXState to TX_TRSM.

MAC80211.refreshFrameTime():if the current time of the simulation is bigger by one frame

time than the local current time then it means that all the actions performed in the last frame time are
gone and it has to reset its channelState , RxState and TxState to Idle.

Enhanced CSMA/CA protocol :

Broadcast messages will play a much bigger role in vehicular environments than unicast
messages because the communication between cars is mainly to send emergency and vehicle state
messages , which must be broadcasts because everybody must have access to them.When a broadcast
frame is sent no ACK or RTS control frames are used.

Some problems with broadcast messages:

- because of the lack of explicit acknowledgement for broadcast frames there is no

retransmission possible for failed broadcast transmissions. A failed unicast transmission can be
detected by the lack of an ACK from the receiver but in broadcast messages we cannot use ACKs
because the ACK explosion problem would occur , meaning that every receiver would immediately
send an ACK to the transmitter , thus flooding the transmitter.
-the hidden terminal problem exists because RTS/CTS is not used. The IEEE 802.11 protocols
use an optional RTS/CTS handshake before sending an unicast packet but broadcast messages cannot
use RTS/CTS because it would flood the network.. Because RTS/CTS is not used channel reservation
is not possible.
- the Contention Window does not change because there is no MAC-level recovery on
broadcast frames. In IEEE 802.11 protocols the Contention Windows size is increased each time a
failed transmission is detected but because in broadcast messages there is no detection of failed

22

messages the Contention Window does not change.This may lead to excessive collisions if a lot of
nodes contend access.

The enhanced broadcast protocol:

The main idea is that a node in a VANET is able to detect collision or congestion by analyzing
the percentage of received packets.In a VANET a node will broadcast its status to its neighbors every
100ms . While a node does not know if the packets it sent were successful it can detect the exact
percentage of packets received from its neighbors. Based on this feedback a node can dynamically
adjust the parameters it uses such as Contention Window size, transmission rate , transmission power
to improve the delivery rate of the broadcasts.
For example , on a crowded highway or in an intersection the number of vehicles contending
for access can be high.
The vehicle MAC Layer records the number of ok received packets and it compares this value
with the total packets received by the Physical Layer .Dividing the first value by the second one we
can obtain a percentage of received packets .Based on this percentage which is calculated every 4
TRANSMISSION TIME FRAME we can increase or decrease the size of the Contention Window.
The MAC Layer performs the adjustment of the contention window in the method
recalculateCW() where the new percentage of ok received packets is compared with the last one , and
if their difference is bigger than a given threshold then the contention window is increased , else if the
negative difference between them is higher that a given threshold then the contention window is
decreased.
The back-off algorithm uses this contention window as follows : every time the vehicle wants
to send a package the back-off timer is selected as a random number between 0 and the current
contention window. Then the back-off timer is used as described in the CSMA/CA protocol.

Message Scheduler the EDCA mechanism : one of the advantages of DSRC is that it
contains a scheduler of incoming and outgoing messages depending on the importance of the message
( safety or non-safety) . This scheduler will prioritize messages for different classes of applications (
Forward Collision Warning , etc ) and it will also coordinate messages between the 7 channels ( 1
control and safety channel and 6 for no-safety communication).The Enhanced Distributed Channel
mechanism is such a scheduler [11] .

23

EDCA enhances the original DCF to provide prioritized QoS, i.e. QoS based on priority of
access to the wireless medium, and it supports priority based best-effort service such as DiffServ.

Default EDCA Parameters

Prioritized QoS is realized through the introduction of four access categories (AC), which
provide delivery of frames associated with user priorities as defined in IEEE 802.1D.5 Each AC has its
own transmit queue and its own set of AC parameters. The differentiation in priority between AC is
realized by setting different values for the AC parameters. The most important of which are listed
below:

Arbitrary inter- frame space number (AIFSN): The minimum time interval between the wireless
medium becoming idle and the start of transmission of a frame.

Contention Window (CW): A random number is drawn from this interval, or window, for the
backoff mechanism.

TXOP Limit: The maximum duration for which a QSTA can transmit after obtaining a TXOP.

When data arrives at the MAC-UNITDATA service access point (SAP), the 802.11e MAC first
classifies the data with the appropriate AC, and then pushes the newly arrived MSDU into the
appropriate AC transmit queue. MSDUs from different ACs contend for EDCA-TXOP internally
within the QSTA.
The internal contention algorithm calculates the backoff, independently for each AC, based on
AIFSN, contention window, and a random number. The backoff procedure is similar to that in DCF,
and the AC with the smallest backoff wins the internal contention.
The winning AC would then contend externally for the wireless medium. The external
contention algorithm has not changed significantly compared to DCF, except that in DCF the deferral

24

and backoff were constant for a particular PHY. 802.11e has changed the deferral and backoff to be
variable, and the values are set according to the appropriate AC
In our implementation of EDCA we take into account two types of messages : Emergency and
vehicle state messages .The emergency messages are described by the PROT_EMERGENCY
indicative and the vehicle state messages are described by any of the indicatives :
PROT_NEIGHBOR_DISCOVERY , PROT_SETOFCARS. According to the message type which
comes at the MAC layer the contention window is changed to a specific value for every type of
message. If the message type is emergency then the contention window = 1 , else it is 2. The EDCA
mechanism is implemented in the EDCAScheduler() in the MAC80211 class.

The different channels of DSRC will be implemented as different event queues and they will
be used to transmit and receive important safety related messages.

3.2.3 Application Layer

The top layer in the OSI stack is the application layer. This layer provides functions for users
or their programs, and it is highly specific to the application being performed. It provides the services
that user applications use to communicate over the network, and it is the layer in which user-access
network processes reside. These processes include all of those that users interact with directly, as well
as other processes of which the users are not aware.
As with the Application Layer of the TCP/IP stack , the Application Layer of DSRC will
implement some user services and programs .

We have implemented the Application Layer in the Application class and this class
encapsulates 3 DSRC applications which are of major interest .These applications will be described in
greater detail in the following sub-paragraphs.
The Application class contains 4 CarInfo variables , FVehicle, NFVehicle , LAdjancedVehicle
, RAdjancedvehicle which will be used in the Forward Collision Warning and Lane Change Assistance
applications.

25

Forward Collision Warning

The Application layer will implement with specific safety applications such as Forward
Collision Warning . In such an application , every vehicle receives broadcast messages from all the
cars around it and together with the datum about its own speed , acceleration , position can calculate
the probability of a collision . If a collision is imminent , the driver is warned by the system.In such an
application the vehicle will receive messages from all vehicles surrounding it but the only messages
that are of interest are those coming from the vehicles in front of the car [10].

The Forward Collision Warning is implemented as a method of the Application class.This

application uses the following variables:
-

the FVehicle CarInfo type variable to store the vehicle right in front of the host
vehicle and the NFVehicle variable to store the vehicle in front next to the forward
vehicle.

the FVehicleDistance double type variable to store the distance to the forward
vehicle and the NFVehicleDistance to store the distance to the NFVehicle .

the lastFVSpeed and the lastNFVSpeed double variables to store the last received
speed of the FVehicle and the NFVehicle.

the forwardCrashSignal Boolean type variable which will indicate if the car is in
danger of a forward crash

The ForwardCollisionWarning method in Application class received as parameter a data

message and of the message is of type NEIIGHBOR_DISCOVERY or SETOFCARS then the method
tries to see if the message is sent by the Forward Vehicle or the Next Forward Vehicle.
Firstly , the method checks to see if it is a message from the Forward Vehicle by checking if
the distance between the HVehicle and FVehicle is less or equal to the last FVehicleDistance , if the
cars are on the same road, have the same direction and are on the same lane.All this information it is
obtained from the data packet. Then , depending on the direction , if the pointIdx of the FVehicle is
bigger or smaller than the one of the Host Vehicle then this is the FVehicle.
If the FVehicle is found of the FVehicle is null then the method returns because there is no
reason to check for the NFVehicle. Otherwise , the same procedure is employed to search for the
NFVehicle .

26

Consequently , after locating the FVehicle and the NFVehicle the method compares the speed
of these vehicles with their last recorded speed , or if this does not exist , with the speed of the host
vehicle , and if the difference is bigger than a given threshold the there is a big probability of a forward
crash and the forwardCrashSignal switches to true.

The FVehicle and the NFVehicle are being drawn on the main map as white-yellow spheres
every time a car is selected . This is done in the Display class in the display method if the currentCar is
not null ( a car is selected ) then after the display of the neighbors of the car , in the same manner the
FVehicle and the NFVehicle are drawn.
Also , if a car is selected then the info on its FVehicle and NFvehicle is displayed in the right
info scroll bar.

Lane Change Assistance

On the basis of the Forward Collision Warning it can be developed a similar application that
can prevent collisions in intersections or can assist the driver when changing lanes , the messages of
interest being the ones received from the vehicles on the side. This application is called Lane Change
Assistance . It functions the same way Forward Collision Warning works , but this time the messages
of interest are those coming from the vehicles on the side of the host car.

The Lane Change Assistance is implemented as a method in the Application class.This

application uses the following variables:
- the LAdjancedVehicle CarInfo type variable to store the vehicle to the left of the host
car and RAdjancedVehicle to store the vehicle to the right of the host vehicle.
- the LAVehicleDistance double type variable to store the distance to the left vehicle
and the RAVehicleDistance to store the distance to the RAVehicle .
- the leftCrashSignal and the rightCrashSignal to indicate if a left or right crash is
probable.

The LaneChangeAssistance method in Application class received as parameter a data message

and of the message is of type NEIIGHBOR_DISCOVERY or SETOFCARS then the method tries to
see if the message is sent by the Left Adjanced or Right Adjanced Vehicle.

27

Firstly the method checks to see if the car which sent the message is on the same road , has the
same direction , is on a different lane than the host vehicle and if the difference in pointIdx between
the two is equal or less than 1.After this check if the lane of the host vehicle is equal to the lane of the
sending vehicle +1 then it is the Left Adjanced Vehicle else if it is equal to the lane of the sending
vehicle -1 it is the Right Adjanced Vehicle.
If the LAdjancedVehicle exists then the application signals the driver that there is a possibility
of a lateral crash.The same procedure with the RAdjancedVehcile.

As with the FVehicle and the NFVehicle , the LAdjancedVehicle and the RAdjancedVehcle
are drawn on the main map and are displayed as info on the right scroll bar if a car is selected.The
same procedure is employed to do this as for FVehicle and NFVehicle.

Figure 4

Host Vehicle

Next Forward Vehicle

Forward Vehicle

Adjacent Vehicle

Example environment of a Cooperative Collision Warning application

28

Emergency Vehicle Warning System

Another safety application is Emergency Vehicle Warning System . The key intent of the
system is to provide motorist convenient in-vehicle aural visual early warning alerts information
notification to the driver of any on or off road encountered potential hazards and imminent warnings
of danger information.

Examples of situations which would benefit from the Emergency Vehicle Warning System:

Emergency Vehicle Priority

A first responder, or law enforcement officer rushing to an emergency scene or on call to an
accident site or an ambulance rushing to a critical patient may activate the self-contained high-power
directional intelligent beacon to alert drivers traveling on the road ahead of the approaching
emergency vehicle commanding right-of-way use of traffic lanes.

School Bus Warning

A school bus may send at regular moments ( but not very frequent not to occupy the bandwidth
too much) for the purpose of alerting drivers of the impending danger surrounding the vehicles.
Transmission signals may be intelligently programmed and transmitted in the forward (parallel) and/or
reverse direction of the bus, or surrounding (up to 360 degree radius) the bus as needed to alert
approaching vehicles in the vicinity of the potential danger.

The Emergency Vehicle Warning System can be implemented as an application which sends
high-priority flagged messages at regular times on the Control Channel . The high-priority flag of the
messages must be lower that the flag of a message coming from Forward Collision Warning but
respectively higher than the normal ones.

The Emergency Vehicle Warning System is implemented as a method in the Application class
and this application uses another type of message , thus another type of message was made, the
PROT_EMERGENCY . For this purpose , the CarRunningDSRC class overrides the onReceive() and
prepareMessage() methods in its parent class by adding in onReceive() a switch statement where the
emergency messages are passed on to the method in Application class and by adding in

29

prepareMessage() the code to prepare an emergency type message ( type==-1 ) .Also , the
EmeregencyRequest class was made to generate the emergency send events .
The Emergency Vehicle Warning application unpacks the message , and if the sender is on the
same road and has the same direction as the receiver then it is of interest. The application then tries to
determine the position of the sender, and based on its direction and pointIdx on the road it can tell if it
is in front or behind the receiver.Also , based on the lane of the sender the application tries to
determint if it is to the left or to the right of the receiver.

The Emergency Vehicle Warning is a priority application , and because of this we decided to
run this application on a different channel than the rest of the applications. For this purpose , we have
created another array list type event queue in which the send events and the Receive events will be
placed.
For implementing another channel we have constructed the following methods in Engine class:
-

scheduleEventEmergency which inserts the new send or receive event into the
emergency event queue

simulateEmergencyCommunication which transforms the emergency send events

into receive events .

playEventEmergency() which takes every event from the emergency event queue
and depending on its type does appropriate action exactly as in the original
playEvent().

In SimulatedCarInfo , we created another list of receive events meant to be used exclusively

for the emergency receive events . Also , we constructed the appropriate methods to be able to work
with this list.

The different channels of DSRC are a very important aspect because they reduce the collisions
from a single channel and give bigger priority to the important messages such as those used in an
Emergency Vehicle Warning application. On the simulation results section we will demonstrate the
effectiveness of this type of communication.

Some other safety applications that can be implemented are Pre-Crash Warning , Left Turn
Assistant or Curve Speed Warning and will be considered for future work.

30

UML Diagram of the DSRC architecture

31

3.3 Radio Propagation Models Implementation

The radio propagation models can be divided into two main categories : large scale models
dealing with the propagation in a large area and small scale propagation ( sometimes called fading
models ) calculate signal strength according to small movements.
Next in this chapter , the three propagation models implemented in the simulator will be
described in detail.

3.3.1 Two Ray Ground

In a wireless communication a single line-of-sight path between two mobile nodes is seldom
the only means of propagation , thus the two-ray ground reflection model considers both the direct
path and a ground reflection path. If we consider the effect of the earth surface, the expressions for the
received signal become more complicated than in case of free-space propagation. The main effect is
that signals reflected off the earth surface may (partially) cancel the line of sight wave.

The received power at distance is predicted by the formula :

Where Gt and Gr are the gain of the receiver and respectively the transmitter antenna , ht and hr are
the heights of the receiver and transmitter antennas , d is the distance between the receiver and the
transmitter and L is the system loss ( usually around 1 ).
However, the two-ray model does not give a good result for a short distance due to the
oscillation caused by the constructive and destructive combination of the two rays thus at a distance
lower than 4 * ht * hr / the free space model is used , for any distance over the two-ray model is
used.

32

The Two Ray Ground model is implemented in TwoRay class , and it contains a static method
which applies the above mentioned algorithm. The parameters of the function are the power
transmitted in dBm and the distance between the transmitter and the receiver and the function returns
the received power at distance in dBm.

3.3.2 Shadowing
The free-space and the two ray ground model represent the received power as a deterministic
function and the communication range as a perfect circle . Actually , the received power at a certain
distance is a random variable because of the multipath propagation effects . A more general and
widely used model is the shadowing model.
The shadowing model consists of two parts.The first part calculates the mean received power at
a distance by calculating the path loss. The power loss is given by the formula:

where d is the distance between the transmitter and the receiver , d0 is a reference distance and
the Pr(d0) is the received power at the reference distance calculated with the Free Space model , is
called the path loss exponent.
The second part of the shadowing process reflects the variation of the received power at a
distance by adding to the power loss a log- nomal random variable between 0 and the standard
deviation of the shadowing model.
Finally the received power is calculated as Pr=Pr(d0) * pow(10,powerloss/10);

The shadowing model is implemented in the Shadowing class and it has a static method which
given the parameters transmitter power and distance returns the received power at distance. The class
also takes some global parameters such as the reference distance ( 1 meter) , path loss exponent ( 2.0
for open space environment and 4.0 for urban environment ) and the shadowing deviation ( 4.0 ).

33

3.3.3 Ricean fading

Ricean fading is a type of small scale fading caused by the movement of the vehicles or of
other objects in the environment. One main characteristic of this movement is the Doppler spreading.
Doppler spreading is is the change in frequency and wavelength of a wave that is perceived by an
observer moving relative to the source of the waves. In our case the frequency of the transmitted radio
wave is perceived differently by the receiving radio device.This could be a major impediment in real
wireless communications so it is important that we simulate it [8].
This fading can be modeled by using frequency domain random numbers with the right
statistics and then by performing spectral shaping on the data with the use of the Doppler spread.
Computation of the dataset is done by generating in-phase and quadrature-phase components
using a Gaussian distribution .
Our dataset initially contains a sequence of in-phase and quadrature components which are
combined with the Ricean K factor to create the fading envelope.

The formula for calculating the resulting received power after applying Ricean fading to it is:

where r is the resulting received power , P is the large scale calculated received power ( with two ray
ground ) , K is the Ricean factor , x1 is the in-phase component and x2 is the quadrature component.

The Ricean model is implemented in Ricean class . The class contains :

- the maximum Doppler frequency fm , which is max_velocity/ , where max_velocity is the
maximum speed of the object ; in the simulator we have 2 values for this variable , one for urban
traffic and one for highway traffic.
- two vectors for storing the in-phase and quadrature Gaussian distribution which it reads from
a file.
- the Ricean K factor ( normally 7.8)

If Ricean model is selected in the start menu , then in the Engine class a Ricean object is
instantiated , at which moment it stores the Gaussian distribution file in its two vectors.
The class contains the getPr method which has the transmitted power and the distance between
the transmitter and the receiver and the current simulation time as parameters.It calls the static method

34

in TwoRay class to calculate the large scale received power, it calculates the time index in relation
with the current simulation time and the maximum Doppler frequency .Then it makes an interpolation
with this time index in the Gaussian distribution vectors to calculate the in-phase and quadrature
components .After that it applies the formula described above and it returns the received power at a
distance .
The theoretical aspects are described in [6].

UML Diagram of Propagation Models

35

3.4 Statistical Information Implementation

In our implementation of DSRC , we have devised a module which during the simulation ,
gathers datum about some specific events in the simulation , it stores the datum until the simulation is
over and then it displays it in the form of several charts and tables. Below we will describe in detail
this process of gathering datum and displaying it .

The main class of the statistical architecture is the DSRCStatisticComponent class which
includes different types of simulation datum. This statistic component represents the value of a
specific data in 1 minute of simulation time.
The DSRCStatisticComponent includes the following variables :
- weak packets sent packets but too weak to be received
- total packets the total packets received by all the cars
- corrupted packets packets with a power level too low to decode the Physical and PCLP
header
- collision packets
- lost TX , RX packets packets that were dropped because the DSRC device was in a transmit
or receive state
-lost PER packets packets with a power level too low for the data to be decoded
- OK packets packets received ok
- the number of cars in 1 simulation minute
- cumulative packets received from Forward Vehicle , Next Forward Vehicle , Left Adjanced
Vehicle , Right Adjanced Vehicle.
- Inter Reception Time from FV, NFV , LAV , RAV
- emergency type packets sent and received

The DSRCStatistics class includes an array list of DSRCStatisticComponents and also this
class builds the JFrame which contains the statistical charts and it uses the DSRCChart class to build
the JFrame.. After every minute of simulation another DSRCStatisticComponent is added to the list in
DSRCStatistics .

The DSRCChart class is an extension of ApplicationFrame native class and it uses the
jfree.chart library to build the following charts and tables:

36

the received packets lost/ok which uses the different types of packets received

the received packets by transmitter which uses the received packets from the
FV,NFV,LAV,RAV

the Inter Reception time by Transmitter which uses the inter reception times from
the 4 types of transmitters

the emergency messages which uses the sent and received emergency messages

the number of cars per simulation minute table which uses the number of cars
counted in every simulation minute.

The statistics window appears only after the simulation is over , by pressing the Close button
on the lower right corner of the main application window.

Figure 5 The statistical window

Besides viewing the statistics charts , the user has the possibility of saving all the statistical
data in an Excel file by pressing the Write to File button in the lower left side of the screen. The
program will write the Receive packets lost/ok , received packets by transmitter , IRT by transmitter

37

and emergency messages charts statistical data in a .xls file named with the current time and date for
unicity.

3.5 Other Implementation Choices

Cumulative interference and noise level

Usually interference among independent OFDM systems can be modeled very well as
Gaussian noise, thus the WirelessPhy adds the received power from an interference source to its local
interference and noise level.

SINR and PER Frame Reception

In the simulator one of the decisions of accepting a frame is the comparison of that frames
SINR ( its own received power / the total interference + noise ) with a certain SINR threshold ( for
each modulation and code rate used it differs ) . If it is higher then the frame is received ok .The SINR
threshold should be interpreted as a threshold over which 90% of the 1000 byte frames would be
decoded correctly.
Another decision upon accepting a frame is its PER value , calculated by the MAC layer to see
if the rest of the frame body ( the mac header and data body ) can be decoded.

Uniform received power for the entire frame

The received power of each part of a reasonably long frame ( a few hundred bytes ) should
experience similar radio propagation pathloss and fading because the guard interval in the OFDM
system is large enough to handle the multi-path channel of a wireless communication .

Graphical User Interface Additions

In order for the user to be able to select to use DSRC over 802.11 or , to use one of the three
propagation models or to choose if they want to run DSRC with or without one of its functionalities
we added three panels to the main configuration panel.

38

The first panel contains the options for choosing between DSRC or 802.11 protocol
communication.
The second pane contains the options for choosing one of the three propagation models : Two
Ray Ground , Shadowing and Ricean fading.
The third panel contains three check boxes for using or not using the following three DSRC
functionalities:
- DSRC physical parameters : transmitter power is 33 dBm and SINR Threshold is higher than
the standard SINR Threshold to simulate the DSRC modulation scheme
- CSMA/CA Differential CW : the enhanced Differential Contention Window algorithm
explained in the MAC Layer sub-section
- DSRC Multiple Channels : instead of one communication channel , two channels are used,
one for standard messages and one for emergency messages.

The new main configuration window

39

4. Simulation Results

In this section we present the test cases we ran and the results we obtained . We used the
simulator described in section 3 with the DSRC implementation and the three propagation models.

4.1 Simulation Setup

The simulation was run on the Apaca scenario in TrafficView Simulator which is a cross
intersection , each road has 3 lanes for each direction . The average number of cars is between 50 and
90 every minute . The simulations run for 7 simulation minutes ( 4 real time minutes ).The packet size
varies between 200 and 600 bytes ( besides the phy/mac payload) .
The transmission range between vehicles is 200 m , the transmitted power of a frame is 15
dBm ( 0.0316 W ) .
In the next sub-sections we will present four types of tests which will demonstrate the
efficiency of some of the mechanisms in DSRC.

4.2 CSMA/CA protocol enhancement

In this sub-section we present the advantages of the Differential Contention Window Back-off
Algorithm in the CSMA/CA protocol described in the MAC implementation section. Briefly, this
algorithm checks the percentage of received packets , and based on this feedback a node can
dynamically adjust the parameters it uses such as Contention Window size, transmission rate ,
transmission power to improve the delivery rate of the broadcasts. We have run 2 simulations , one
with the Differential Algorithm and one without and we have compared the results .

40

Figure 6 DSRC broadcast performance with Differential CW Algorithm

Sim minute

No of cars

26

47

70

90

118

103

90

2,496

4,282

4,527

5,5

5,03

5,388

2,187

13,046

23,723

29,412

35,47

30,553

31,532

Collision
RX lost

Figure 7 DSRC broadcast performance without Differential CW Algorithm

41

Sim minute

No of cars

26

47

70

90

118

103

90

3,975

5,193

4,559

4,652

5,23

4,924

5,424

16,745

29,384

31,057

36,302

30,865

30,844

Collision
RX lost

Figures 5 and 6 show the DSRC packet broadcast performance analyzing each type of
breakdown reason. The X axis represents the percentage of the respective type of packet out of the
total number of packets.

The reasons are tagged in the charts as following :

Weak : when a frame arrives at a node in idle mode but its power is below the Carrier Sense
threshold then the frame is rejected because the node cannot detect it as a frame, it just detects noise.

Collision : when a frame has enough power to decode the preamble , PCLP header and the rest
of the frame and the receiving node is idle but other frame arrive at the same time and the ratio of the
first frame to the sum of the others is below a certain threshold.This situation describes a collision of 2
or more frames.

Ok : the received frame has enough power for Preamble , PCLP header decoding , the
receiving node is in idle mode , the PER is checked ok . This frame is received and can be interpreted.

Tx : the received frame was rejected because the receiving node was in Txing mode.

Rx : received frame was rejected because the receiving node was in Rxing mode.

Per : the received frame has enough power for preamble , PCLP header decoding but the Per
check failed meaning that it does not have enough power for the rest of the data frame decoding

42

Corrupted : the frame is above the Carrier Sense threshold , it can be sensed by the node , but it
is below the receive threshold . The frame is tagged by Physical as corrupted and checked by MAC
comparing its SINR with the SINR Threshold .

The table contains the percentages for the collision packets and for the lost RX packets. Also ,
the table contains the number of cars /square km in every simulation minute to show the traffic
congestion level.

As we can see from the two charts and tables , the Differential Contention Window algorithm
performs better for a relative free traffic environment when the percentage of lost RX packets is lower
by 3 to 5 % than the percentage for the simulation without Differential CW and also the percentage of
received ok packets is higher by 3-5 % . On the other hand , in high traffic conditions , such as minutes
5, 6,7 the simulation with the Differential CW algorithm performs just as well as the simulation
without it , when the percentage of lost Rx packets is slightly lower than the one for the simulation
without the algorithm but the percentage of collisions is slightly higher.

In conclusion , the Differential CW algorithm performs better in low traffic conditions , but
performs almost the same in high traffic conditions.

4.3 DSRC Communication channels

In this sub-section we present the advantages of having more communication channels in
DSRC . In the simulations with two communication channels , we have constructed one channel for
vehicle state messages and one for emergency messages. In the simulation with only one channel ,
both types of messages are transmitted and received on the same channel . On both simulation types
we have made a scenario where during several minutes emergency messages are being transmitted by
a number of vehicles. In the following 2 charts we present the reception rate of the emergency
messages in both situations .

43

Figure 7 DSRC emergency messages reception rate with two comm. channels

sim
minute

sent

2169

3122

1938

recv

1632

2184

1673

Figure 8 DSRC emergency messages reception rate with one comm. channel

44

sim
minute

sent

2238

3619

2026

recv

1268

1483

1194

The two charts present the emergency message type reception rate . The two types of chart
series represent:
- Emergency Message Recv : the total number of messages received Ok by the vehicles per
simulation minute
- Emergency Message Sent : the total number of messages sent by the vehicles per simulation
minute.

As can be seen from the two charts , the simulation run with 2 channels has a much bigger
reception rate than the simulation run with only one channel . The difference of received emergency
messages between the two situations is around 800 packets out of a total sent of around 3000 which
represents roughly 25% of the total.
Given the fact that the emergency message type should have high priority in vehicular
communication , the communication channels in DSRC definitely have a higher performance than the
single channel in 802.11.

4.4 DSRC physical parameters

In this sub-section we tested the DSRC physical parameters , such as modulation parameters
and transmission power. To simulate the modulation parameters we changed the value of the SINR
Threshold and we also changed the vehicle transmission power. We ran two simulations , one with
802.11 physical parameters and one with DSRC physical parameters.

45

Figure 9 Simulation with DRC physical parameters

Sim minute
No of cars
Corrupted
Weak

1
26
0
15

2
47
1,01
1,2

3
70
0,56
0,67

4
90
0,489
0,5

5
118
0,54
0,52

6
103
0,6
0,57

7
90
0,62
0,6

Figure 10 Simulation with 802.11 physical parameters

Sim minute
No of cars
Corrupted
Weak

1
26
0
15,3

2
47
3
1,3

46

3
70
2,21
1,1

4
90
2,02
1,023

5
118
1,89
1,128

6
103
1,99
1,01

7
90
2,06
0,88

The two charts above represent the percentage out of the total packets of lost packets due to
corrupted state ( not enough power to decode the preamble and PCLP header ) and weak packets ( not
enough power to be sensed by the receiver) , all of these percentages per simulation minute. The
tables show the specific values of these percentages and also show the number of cars per square km .

As we can see from both charts and tables the DSRC physical parameters give a lower
percentage of corrupted packets than the 802.11 physical parameters ( a difference of around 2%) and
the percentage of weak packets is about the same.

4.5 DSRC Applications Performance

In this sub-section we have tested the impact of the above described physical parameters ,
Differential CW and multiple channels mechanisms upon the Cooperative Collision Warning
Applications such as Forward Collision Warning and Lane Change Assistance described in the last
chapter . We ran 2 simulations , the first with the two mechanisms on and the second without them.

Figure 11 CCW Application Cumulative received packets with

the two mechanisms

47

sim minute

682

5793

9150

9508

10015

10743

13032

NFV received

47

1704

3177

2846

4310

3889

4509

LAV received

37

48

48

39

46

19

RAV received

20

40

45

30

35

20

FV received

Figure 12 CCW Applications Cumulative received packets

without the two mechanisms

sim minute

771

6291

7275

8970

11860

10970

9420

NFV received

54

1428

3214

3773

4583

3788

3527

LAV received

38

56

95

54

44

RAV received

40

62

20

32

34

FV received

The first two charts represent the cumulative number of received packets from the Forward
Vehicle , Next Forward Vehicle , Left Adjanced Vehicle , Right Adjanced Vehicle during the
simulation run , with the two mechanisms and without the two mechanisms.

From analyzing these results we can observe that the simulation run with the mechanisms tends
to have a larger number of received packets for the FV and the NFV and slightly lower for the LAV

48

and RAV . This denotes that the Forward Collision Warning application would run better with the
Differential CW and multiple communication channels .

Figure 13 CCW Applications inter frame reception time with

the two mechanisms

sim
minute

FV IRT

0,794

0,336

0,353

0,375

0,461

0,39

0,47

NFV IRT

1,424

0,409

0,393

0,334

0,405

0,4

0,529

LAV IRT

0,1

0,26

0,201

0,282

1,208

1,03

0,319

RAV IRT

6,06

0,3

0,223

0,405

2,672

1,83

1,3

49

Figure 14 CCW Applications inter frame reception time

without the two mechanisms

sim minute

FV IRT

0,555

0,315

0,492

0,368

0,49

0,458

0,634

NFV IRT

0,382

0,503

0,456

0,405

0,54

0,56

0,7

LAV IRT

14

0,47

1,03

0,446

0,5

0,349

0,466

RAV IRT

29

0,16

0,79

0,67

0,636

1,2

0,5

The last two charts represent the average inter frame reception time for every simulation
minute for the four specific vehicles with the mechanisms and without them.

From these charts and the results we can observe that in the case of the simulation run with the
mechanisms we see a lower IRT average for all vehicles compared with the simulation run without the
mechanisms which has a significantly higher IRT average which , especially in the case of the
Forward Vehicle and Next Forward vehicle could mean the difference between success and failure.

In conclusion , the Forward Collision Warning and the Lane Change Assistance applications
tend to perform better with the Differential CW and multiple communication channels because they
have a higher number of received packets which means a better understanding of the position of the

50

surrounding vehicles and they tend to have a lower IRT than without the mechanisms.This is more
important in the case of the Forward Collision Warning application when time is more critical ( even
in the amount of milliseconds ) than the Lane Change Assistance.

4.6 Radio Propagation Models Performance

In this subsection we have tested the capability of the DSRC Physical and MAC layers to
receive and to transmit packages given the different types of radio propagation models .

The following 3 charts are 3 simulation runs on the for each of the 3 propagation models ( Two
Ray Ground , Shadowing , Ricean ) and they represent on the Y axis the percent of each type of packet
drop reason out of the total number of packets received by the number of cars per simulation minute
represented on the X axis.

Figure 15

DSRC broadcast performance with Two Ray Ground

51

sim minute
weak
corrupted
lost per

635

802

2689

2448

3270

2666

2472

1819

4690

5150

6528

6693

6294

813

2751

10219

13159

15167

14712

12392

Figure 16

DSRC broadcast performance with Shadowing

sim
minute
weak
corrupted
lost per

635

999

2478

2203

3247

2826

2706

1464

3518

3741

4688

5165

5621

708

2958

9490

13961

15488

14160

12703

52

Figure 17

DSRC broadcast performance with Ricean fading

sim
minute
weak
corrupted
lost per

693

1130

3959

3191

3985

4114

4128

2000

5252

5939

6185

7332

8151

794

2407

11160

12641

15350

14492

13196

The new DSRC protocol simulation provides a statistical research of the capability of DSRC to
receive incoming packets based on the three propagation models . Figures 5,6,7 show the DSRC
packet broadcast performance with the 3 propagation models analyzing each type of breakdown
reason.

The reasons are tagged in the charts as following :

Weak : when a frame arrives at a node in idle mode but its power is below the Carrier Sense
threshold then the frame is rejected because the node cannot detect it as a frame, it just detects noise.

53

Per : the received frame has enough power for preamble , PCLP header decoding but the Per
check failed meaning that it does not have enough power for the rest of the data frame decoding

Corrupted : the frame is above the Carrier Sense threshold , it can be sensed by the node , but it
is below the receive threshold . The frame is tagged by Physical as corrupted and checked by MAC
comparing its SINR with the SINR Threshold .

From the three charts we can see that the biggest packet drop reasons concerning the received
power modeled by the propagation models it is the PER packet lost , followed by the Corrupted
packets and finally the Weak packets.
In the case of the Two Ray Ground and Shadowing , the weak and lost PER packets are in
bigger numbers in the Shadowing modeling than the ones in Two Ray Ground especially in the
minutes with a higher number of cars but TRG has a higher number of Corrupted packets , concluding
that Shadowing models the behavior of radio waves better in bad traffic conditions , thus simulating
the multipath effect better than the Two Ray Ground model.
The Ricean model has a bigger number of weak, corrupted and lost PER packets overall ,
meaning that it simulates the multipath propagation corresponding to heavy traffic in minutes 5, 6, 7
but it also simulates the Doppler effect corresponding to the speed of the vehicles .

We can conclude that Shadowing is slightly better than Two Ray Ground at simulating
multipath propagation and Ricean fading is better than the other two models , because it can simulate
multipath propagation but also the Doppler effect.

The following 3 charts show the total number of send failures by reason of failure and with
respect to the average number of cars per simulation minute

54

700

Number of failed send packets

600

500

400
Send Faliure RX
Send Faliure Noise

300

200

100

0
13

26

47

70

90

118

103

90

Average number of cars/simulation minute

Figure 18

DSRC with Two Ray Ground

700

Number of failed send packets

600

500

400
Send failure RX
Send failure Noise

300

200

100

0
13

26

47

70

90

118

103

Average number of cars/simulation minute

Figure 19

55

DSRC with Shadowing

90

800

Number of failed send packets

700
600
500
Send failure RX

400

Send failure Noise

300
200
100
0
13

26

47

70

90

118

103

90

Average number of cars/simulation minute

Figure 20

DSRC with Ricean

Figures 8,9,10 describe the capability of the DSRC MAC layer to send packets with respect to
the channel state indication from the Physical layer. In our simulation we have discovered 2 reasons
for the MAC to reschedule the sending of a packet , meaning that it employs the backoff procedure .
These reasons are tagged on the charts as follows:
Send failure RX : the MAC layer is signaled that a Carrier Sensible Frame has arrived at
Physical and the Physical has entered Rx Mode.
Send failure Noise : the MAC layer is signaled by Physical that the level of interference and
noise on the channel has risen above a certain threshold and the MAC employs the backoff procedure.
The Send failure Noise is better simulated with the Shadowing and Ricean propagations where
we can see that when the number of cars increases significantly in an area the send failure noise
increases respectively and when the number of the cars decreases the send failure decreases as well .
This fact cannot be observed in the Two Ray Ground model.

56

5. Conclusions and Future Work

This project has two main contributions. Firstly , it implements and analyzes the DSRC
protocol highlighting its differences to the 802.11 at the Physical , MAC and Application layers .
difference which in the case of a mobile environment tend to make a big impact on the broadcast
performance and on the applications running on DSRC.
Secondly, it implements and analyzes three radio propagation models , the Two Ray Ground ,
Shadowing and Ricean models . The analysis done on these models reflects the ability of each of them
to simulate the real environment in which the radio waves propagate , such as multipath propagation
and the Doppler spreading due to vehicle speed.
In the first test we compared the CSMA/CA protocol of DSRC with the Differential
Contention Window mechanism and without , and we discovered that the first does a much better job
at transmitting broadcast messages with a high rate of success especially in low traffic scenarios.
DSRC with Differential CW reduces the total number of packets lost to RX and Collision by roughly 3
to 5% in a low traffic situation .
In the second test , we simulated a one channel communication versus a two channel
communication , in which test the vehicles were sending two types of messages , state vehicle and
emergency types , the latter type being a priority type of message. While the one channel
communication scenario had a emergency message delivery rate of

40% , the two channel

communication scenario had a emergency message delivery rate of 70% , which adds up to a
difference of 30% .
In the third test , we compared the efficiency of the Cooperative Collision Warning
applications in the situation when both mechanisms described above were used and the situation when
they were not used. In the first situation , the number of received packets which these applications can
use was around 5% higher than the latter situation , thus not making a big difference but in the case of
inter frame reception time , the first situation has a lower IRT than the second one for all applications ,
difference which on the road can mean the difference between life and death.
In the fourth test we compared the DSRC physical parameters to the one in 802.11 and we
discovered that the first perform better , lowering slightly the number of corrupted and weak packets
compared to the latter.

57

The last test analyzes the three propagation models , Two Ray Ground , Shadowing and Ricean
Fading. The best simulation of real radio propagation was in the case of Ricean Fading , which
simulated both multipath effect and Doppler spreading , while the Shadowing and Two Ray Ground
models were roughly at the same level .
As part of our future work , we plan to analyze a Differential transmission power and
transmission rate at the MAC layer and to implement a communication channel for private
applications.

58

6. References
[1]

Qi Chen , Daniel Jiang , Vikas Taliwal , Luca Delgrossi : IEEE 802.11 based Vehicular

Communication Simulation Design for NS-2

[2]

Mineo Takai , Jay Martin , Rajive Bagrodia : Effects of Wireless Physical Layer Modeling in

Mobile Ad Hoc Networks

[3]

Tamer ElBatt , Siddhartha K Goel , Gavin Holland , Hariharan Krishnan , Jayendra Parikh :

Cooperative Collision Warning Using Dedicated Short Range Wireless Communications

[4]

Qing Xu , Tony Mak , Raja Sengupta : Vehicle-to-vehicle Safety Messaging in DSRC

[5]

C.L. Robinson , L. Caminiti , D. Caveney , K.Laberteaux : Efficient Coordiantion and

Transmission of Data for Cooperative Vehicular Safety Applications , 2006 Edition of VANET

[6]

Arne Schmitz , Martin Wenig The effect of radio wave propagation model in Mobile Ad-Hoc

Networks

[7]

Victor Gradinescu , Cristian Gorgorin , Raluca Diaconescu , Valentin Cristea , Liviu Iftode :

An Integrated Vehicular Ad-Hoc Network Simulator for vehicular ad-hoc networks

[8]

Ratish J. Punnoose, Pavel V. Nikitin, and Daniel D. Stancil : Efficient Simulation of Ricean

Fading within a Packet Simulator

[9]

IEEE P802.11pTM/D2.01Draft Standard for Information Technology -Telecommunications

and information exchange between systems

[10]

Xue Yang , Jie Liu , Feng Zhao , Nitin H. Vaidya : A Vehicle-to-Vehicle Communication

Protocol for Cooperative Collision Warning

[11]

Boris Bellalta, Cristina Cano, Miquel Oliver, Michela Meo : Modeling the IEEE 802.11e

EDCA for MAC parameter optimization

59

[12]

Nathan Balon and Jinhua Guo : Increasing Broadcast Reliability for Vehicular Ad Hoc

Networks

[13]

Inanc Inan, Feyza Keceli, and Ender Ayanoglu : Analysis of the 802.11e Enhanced Distributed

Channel Access Function

[14]

Erez Dagan ,Ofer Mano, Gideon P. Stein, Amnon Shashua : Forward Collision Warning with a

Single Camera
[15]

Simon Chung and Kamila Piechota : Understanding the MAC impact of 802.11e

[16]

The NS-2 Documentation page : http://www.isi.edu/nsnam/ns/ns-documentation.html

[17]

Ramez Gerges : ITS Wireless Interoperability for First Responders

[18]

Radio Propagation Models :

http://people.deas.harvard.edu/~jones/es151/prop_models/propagation.html

[19] Byung-Seub Lee, Choon Sik Yim, Dong Hyun Ahn, and Deock Gil Oh : Performance
Evaluation of the Physical Layer of the DSRC Operating in 5.8 GHz Frequency Band
[20] Davide Sormani, Gabriele Turconi, Paolo Costa, Davide Frey, Matteo Migliavacca and Luca
Mottola : Towards Lightweight Information Dissemination in InterVehicular Networks
[21] Tony K. Mak, Kenneth P. Laberteaux, Raja Sengupta : A Multi-channel VANET Providing
Concurrent Safety and Commercial Services
[22] David R. Choffnes Fabi and E. Bustamante : An Integrated Mobility and Traffic Model for
Vehicular Wireless Networks

60

7. Annex
This section presents some of the important classes in the project .
WirelessPhy class :
public class WirelessPhy
{
private int stateMachine;
private NoiseMonitor noiseMonitor;
//
the duration of a frame receive ; this time is taken from the crtTime in
Engine.java
private int currentTime;
//the Signal to Interference/Noise Ratio of the current frame
private double SINR;
//if the ratio of the strongest sgignal to teh sum of the others is less
tahn this value then they collide
private double cpThreshold=Globals.CP_THRESHOLD;
//if a frame has a receievd power below this value then it is too weak to be
received.
private double csThreshold;
//if a frame has a received power below this value then it can be received
by phy but it is corrupted
private double rxThreshold;
private double txPower=Globals.TRANSMITTER_POWER;
private

int

propagationType=Engine.propagationModel;

private double totalPower=0;

private double maxPower=0;
private double SINRThreshold=Globals.SINRThresholdBPSK;
private int totalReceived;
public WirelessPhy(int currentTime)
{
stateMachine=Globals.IDLE;
noiseMonitor=new NoiseMonitor(fromDBmToW(Globals.ThermalNoise));
this.SINRThreshold=Globals.SINRThresholdBPSK;
this.csThreshold=Globals.CS_THRESHOLD_S;
this.rxThreshold=Globals.RX_THRESHOLD_S;
this.currentTime=currentTime;
this.totalReceived=0;
}

61

public ReceiveEvent recvFromChannel(List<ReceiveEvent> receivedSignals,int

currentTime)
{
//DsrcFrame frame=new DsrcFrame();
int noSignals=0;

//check stateMachine
if(this.stateMachine==Globals.IDLE)
{
ReceiveEvent best=null;
for(ReceiveEvent re : receivedSignals)
{
double receivedPower=0;
Road r1 = (Road)
Globals.map.roads.get(re.sender.getRoadIdx());
Point p1 = (Point) r1.points.get(re.sender.getPointIdx());
Road r2 = (Road)
Globals.map.roads.get(re.receiver.getRoadIdx());
Point p2 = (Point)
r2.points.get(re.receiver.getPointIdx());
double R = GPSutil.distance(p1, p2);
R*=1000;
switch(this.propagationType)
{
case Globals.SHADOWING
:receivedPower=Shadowing.getPr(fromDBmToW(this.txPower),R,true);
break;
case Globals.TWO_RAY_GROUND:
receivedPower=TwoRay.getPr(fromDBmToW(this.txPower),R);
break;
case Globals.RICEAN:
receivedPower=Engine.riceanModule.getPr(fromDBmToW(this.txPower),R,currentTime);
break;
}
if(receivedPower>this.csThreshold)
{
this.totalPower+=receivedPower;
noSignals++;
}
if(receivedPower>this.maxPower)
{
maxPower=receivedPower;
best=re;
}
if((re.getMessage())[0]==Globals.PROT_EMERGENCY)
Globals.EMERGENCY_SENT++;
}

Globals.DSRC_PACKETS_TOTAL+=receivedSignals.size();

62

this.totalReceived+=noSignals;
Globals.DSRC_PACKETS_LOST_WEAK+=(receivedSignals.size()noSignals);
if(best==null)
return null;
if(maxPower<this.csThreshold)
{
//weak signal
this.noiseMonitor.addInterference(totalPower);
return null;
}
else
{
this.noiseMonitor.addInterference(totalPower-maxPower);

//can decode the preamble and phy header

this.setSINR(maxPower);
if(maxPower>this.rxThreshold)
{
//frame received ok
this.stateMachine=Globals.RXing;
send frame to MAC
Globals.DSRC_PACKETS_LOST_RX+=noSignals-1;
return best;

//

}
else
{
if(!this.checkCollision(maxPower))
{
//collision
Globals.DSRC_PACKETS_LOST_COLLISION+=noSignals;
this.noiseMonitor.addInterference(maxPower);
return null;
}
//tag frame as corrupted and send to mac
Globals.DSRC_PACKETS_LOST_CORRUPTED+=noSignals-1;
best.setSender(null);
return best;
}
}
}
//in transmit mode
Globals.DSRC_PACKETS_LOST_TX+=receivedSignals.size();

63

return null;
}
public byte[] sendToChannel(byte[] message,int currentTime)
{
//if(this.stateMachine==Globals.IDLE)
//{
//PCLP frame formation - make a packet out of the received frame
//byte[] phyHeader=new byte[3];
//byte[] preamble=new byte[12];
//DsrcPacket packet=new DsrcPacket(preamble,phyHeader,new
DsrcFrame());
//DSSS modulation
this.stateMachine=Globals.TXing;
return message;
//}
//return null;
}
//
if the layer was transmitting or receiving a frame then after the duration
of a frame it must return back to idle
public void refreshFrameTime(int currentTime)
{
int ret;
if(currentTime-this.currentTime>=Globals.WIRELESS_TRANSMISSION_FRAMES)
{
this.stateMachine=Globals.IDLE;
this.noiseMonitor.refreshInterference();
this.totalPower=0;
this.maxPower=0;
if(currentTime%4==0)
this.totalReceived=0;
}
this.currentTime=currentTime;
}
public NoiseMonitor getNoiseMonitor()
{
return this.noiseMonitor;
}
public DsrcPacket recvFromMac(DsrcFrame frame)
{
return null;
}
//

calculates the SINR for the frame received

public void setSINR(double receivedPower)
{
//this.SINR=10 *
Math.log10(receivedPower/this.noiseMonitor.getInterference());

64

this.SINR=receivedPower/this.noiseMonitor.getInterference();
}
public double getSINR()
{
return this.SINR;
}

//checks the ratio of the strongest signal to the rest to see if there is a
collision
public boolean checkCollision(double receivedPower)
{
if(receivedPower/(this.noiseMonitor.getInterference()this.noiseMonitor.getThermalNoise())>this.cpThreshold)
return true;
return false;
}
//

checks if the IAndN level is above the SINRThreshold

public boolean checkInterferenceAndNoiseLevel()
{
if(this.noiseMonitor.getInterference()>=this.SINRThreshold)
return false;
return true;
}

MAC80211 class :
public class MAC80211
{
private int ChannelState;
private int RXState,TXState;
private int currentTime;
private DsrcFrame currentFrame;
private static final double relError= 1E-12;
//the timer which decides how many simulation times the station will wait
until it will reschedule the packet
private int backoffTimer;
//the sinr threshold for the BPSK code rate
private double SINRThreshold=Globals.SINRThresholdBPSK;
private Random randBackoff;
//contention window ; varies according to the transmission success or
failure
private int CWSafety,CWVehicleState,CW;

65

//the EDCA mechanism

//the safety Access Category in EDCA
private ArrayList<SendEvent> ACSafety;
//the vehicle state Access Category in EDCA
private ArrayList<SendEvent> ACVehicleState;
private double receptionRate;
private int receivedOk;
public MAC80211(int currentTime)
{
this.ChannelState=Globals.CCA_IDLE;
this.RXState=Globals.RX_IDLE;
this.TXState=Globals.TX_IDLE;
this.currentTime=currentTime;
this.currentFrame=new DsrcFrame();
this.randBackoff=new Random();
this.CWVehicleState=2;
this.CWSafety=1;
this.CW=0;
this.backoffTimer=this.randBackoff.nextInt(this.CWSafety+1);
/*
this.CWVehicleState=7;
this.ACSafety=new ArrayList<SendEvent>();
this.ACVehicleState=new ArrayList<SendEvent>();
*/
this.receptionRate=0;
this.receivedOk=0;
}
public int getChannelState()
{
return this.ChannelState;
}
public void setChannelState(int set)
{
this.ChannelState=set;
}
public byte[] recvFromPhysical(ReceiveEvent re,double sinr,int currentTime)
{

//first check SINR to see if frame is corrupted

if(re.getSender()==null)
{
if(sinr<this.SINRThreshold)
{

66

Globals.DSRC_PACKETS_LOST_CORRUPTED++;
return null;
}
}

//CRC check and BER

//should calculate the SINR and BER of the header of the frame in a
different modulation than the rest of the frame
//calculate PER
double
preambleBits=Globals.DSRC_PREAMBLE_LENGTH*8,headerBits=Globals.DSRC_PHYHEADER_LENG
HT*8,dataBits=0;
ByteArrayInputStream byteStream = new
ByteArrayInputStream(re.getMessage());
dataBits=byteStream.available()*8;
double per;
if((per=calculatePER(sinr,preambleBits,headerBits,dataBits))>Globals.DSRC_PE
R_THRESHOLD)
{
//per checked ok
//return data to application
this.RXState=Globals.RX_RECV;
Globals.DSRC_PACKETS_RECEIVED_OK++;
this.receivedOk++;
return re.getMessage();
}
//packet dropped due to bad per check
Globals.DSRC_PACKETS_LOST_PER++;
return null;
}
public byte[] sendToPhysical(byte[] message,int currentTime)
{
//DsrcFrame frame=new DsrcFrame();
//check channel state ; employ backoff timer
if(this.ChannelState==Globals.CCA_BUSY)
{
//channel busy ; pause backoff timer
//this.setBackoffTimer(this.backoffTimer+1);
//the reason for the faliure to send
if(this.RXState!=Globals.RX_RECV)
Globals.DSRC_PACKETS_SEND_FALIURE_RX++;
else
Globals.DSRC_PACKETS_SEND_FALIURE_NOISE++;
if(this.TXState!=Globals.TX_RECV)
this.TXState=Globals.TX_RECV;
return null;
}

67

//EDCA scheduler - sets the CW to the respective value depending on

the message priority
this.EDCAScheduler(message[0]);
//if(this.TXState==Globals.TX_IDLE)
//{
if(this.backoffTimer==0)
{
this.setBackoffTimer(this.randBackoff.nextInt(this.CW+1));
this.TXState=Globals.TX_IDLE;
return message;
}
else
{
this.backoffTimer--;
this.TXState=Globals.TX_RECV;
return null;
}
//}
//return null;
}
public void refreshFrameTime(int currentTime)
{
if(currentTime-this.currentTime>=Globals.WIRELESS_TRANSMISSION_FRAMES)
{
this.RXState=Globals.RX_IDLE;
this.ChannelState=Globals.CCA_IDLE;
if(currentTime%4==0)
this.receivedOk=0;
}
this.currentTime=currentTime;
}
}

Application class :
public class Application
{
//the vehicles around the host vehicle used in forward collision warning and
lane change assistance
private CarInfo FVehicle,NFVehicle,LAdjancedVehicle,RAdjancedVehicle;
private double
FVehicleDistance,NFVehicleDistance,LAVehicleDistance,RAVehicleDistance;
private boolean
forwardCrashSignal,leftCrashSignal,rightCrashSignal,emergencyVehicleSignal;
private double lastFVSpeed,lastNFVSpeed;
private

int

emergencyVehicleHpoz,emergencyVehicleVpoz;

private int currentTime;

68

private

long

lastIRTFV,lastIRTNFV,lastIRTLAV,lastIRTRAV;

public Application()
{
this.FVehicle=this.NFVehicle=this.LAdjancedVehicle=this.RAdjancedVehicle=nul
l;

this.FVehicleDistance=this.NFVehicleDistance=this.LAVehicleDistance=this.RAV
ehicleDistance=30000;

this.forwardCrashSignal=false;
this.leftCrashSignal=this.rightCrashSignal=false;
this.emergencyVehicleSignal=false;
this.currentTime=0;
this.lastFVSpeed=-1;
this.lastNFVSpeed=-1;
this.lastIRTFV=this.lastIRTNFV=this.lastIRTLAV=this.lastIRTRAV=0;
}
//it refreshes the FV , NFV and it calculates the probability of a crash
with these vehicles
public void ForwardCollisionWarning(byte[] bytesReceived,CarInfo self)
{
switch(bytesReceived[0])
{
case Globals.PROT_NEIGHBOR_DISCOVERY:
CarInfo sc=new CarInfo();
sc.wrap(bytesReceived,2);
calculateFCWVehicles(self,sc);
calculateLCAVehicles(self,sc);

break;
case Globals.PROT_SETOFCARS:
ByteArrayInputStream byteStream = new
ByteArrayInputStream(bytesReceived);
byte[] b = new
byte[Globals.NONAGG_RECORD_SIZE];
byteStream.read();
int numberOfRecords =
(byte)byteStream.read();
int messageRoadDirection =
byteStream.read();
int recordsRead=0;
while(recordsRead < numberOfRecords)
{

69

int n = byteStream.read(b, 0,
Globals.NONAGG_RECORD_SIZE);
if (n == -1 || n <
Globals.NONAGG_RECORD_SIZE){
break;
}
recordsRead++;
CarInfo sc2=new CarInfo();
sc2.wrap(b);
calculateFCWVehicles(self,sc2);
calculateLCAVehicles(self,sc2);
}
break;
default:break;
}
//

check FV and NFV speeds and calculate probability of crash

if(this.FVehicle!=null)
{
if(this.lastFVSpeed!=-1)
{
if(self.getSpeed()this.FVehicle.getSpeed()>=Globals.SPEED_DIFFERENCE || this.lastFVSpeedthis.FVehicle.getSpeed()>=Globals.SPEED_DIFFERENCE)
this.forwardCrashSignal=true;
}
this.lastFVSpeed=this.FVehicle.getSpeed();
}
if(this.NFVehicle!=null)
{
if(this.lastNFVSpeed!=-1)
{
if(self.getSpeed()this.NFVehicle.getSpeed()>=Globals.SPEED_DIFFERENCE || this.lastNFVSpeedthis.NFVehicle.getSpeed()>=Globals.SPEED_DIFFERENCE)
this.forwardCrashSignal=true;
}
this.lastNFVSpeed=this.NFVehicle.getSpeed();
}
/*
if(this.currentTime%40==0 && self.getVehicleId()==100)
{
System.out.println("Time
"+this.currentTime/Globals.MINUTE+":"+(this.currentTime%Globals.MINUTE)/Globals.SE
COND+" Car "+self.getVehicleId()+" has
FV:"+((this.FVehicle==null)?"none":this.FVehicle.getVehicleId())+"
NFV:"+((this.NFVehicle==null)?"none":this.NFVehicle.getVehicleId())+
"
LAV:"+((this.LAdjancedVehicle==null)?"none":this.LAdjancedVehicle.getVehicleId())+
"

70

RAV:"+((this.RAdjancedVehicle==null)?"none":this.RAdjancedVehicle.getVehicleId()))
;
}
*/
}
public void LaneChangeAssistance(byte[] bytesReceived,CarInfo self)
{
//calculate the LAV and RAV and calculate the crash probability
switch(bytesReceived[0])
{
case Globals.PROT_NEIGHBOR_DISCOVERY:
CarInfo sc=new CarInfo();
sc.wrap(bytesReceived,2);
calculateLCAVehicles(self,sc);
break;
case Globals.PROT_SETOFCARS:
ByteArrayInputStream byteStream = new
ByteArrayInputStream(bytesReceived);
byte[] b = new
byte[Globals.NONAGG_RECORD_SIZE];
byteStream.read();
int numberOfRecords =
(byte)byteStream.read();
int messageRoadDirection =
byteStream.read();

int recordsRead=0;
while(recordsRead < numberOfRecords)
{
int n = byteStream.read(b, 0,
Globals.NONAGG_RECORD_SIZE);
if (n == -1 || n <
Globals.NONAGG_RECORD_SIZE){
break;
}
recordsRead++;
CarInfo sc2=new CarInfo();
sc2.wrap(b);
calculateLCAVehicles(self,sc2);
}
break;
default:break;
}
if(this.LAdjancedVehicle!=null)
this.leftCrashSignal=true;
if(this.RAdjancedVehicle!=null)

71

this.rightCrashSignal=true;
/*
if(this.LAdjancedVehicle!=null)
System.out.println(self+"
LAV:"+this.LAdjancedVehicle.getVehicleId());
if(this.RAdjancedVehicle!=null)
System.out.println(self+"
RAV:"+this.RAdjancedVehicle.getVehicleId());
*/
}
public void EmergencyVehicleWarning(byte[] bytesReceived,CarInfo self)
{
//if emergency message received activate emergencyVehicleSignal
//check the position of the emergency vehicle
CarInfo sc=new CarInfo();
sc.wrap(bytesReceived,2);
if(self.getRoadIdx()==sc.getRoadIdx() &&
self.getDirection()==sc.getDirection())
{
this.emergencyVehicleSignal=true;
switch(self.getDirection())
{
case 1: if(sc.getPointIdx()>self.getPointIdx())
this.emergencyVehicleVpoz=1;
else
{
if(sc.getPointIdx()<self.getPointIdx())
this.emergencyVehicleVpoz=0;
else
this.emergencyVehicleVpoz=2;
}
break;
case 0: if(sc.getPointIdx()<self.getPointIdx())
this.emergencyVehicleVpoz=1;
else
{
if(sc.getPointIdx()>self.getPointIdx())
this.emergencyVehicleVpoz=0;
else
this.emergencyVehicleVpoz=2;
}
break;
default:break;
}
if(sc.getLane()<self.getLane())
this.emergencyVehicleHpoz=1;
else
{
if(sc.getLane()>self.getLane())
this.emergencyVehicleHpoz=0;
else
this.emergencyVehicleHpoz=2;
}

72

}
Globals.EMERGENCY_RECEIVED++;
//System.out.println("Car "+self.getVehicleId()+" got emergency
message from car "+sc.getVehicleId());
}
//calculates the FV and the NFV
private void calculateFCWVehicles(CarInfo self,CarInfo sc)
{
Road r1,r2 = null;
Point p1,p2 = null;
r1 = (Road) Globals.map.roads.get(sc.getRoadIdx());
p1 = (Point) r1.points.get(sc.getPointIdx());
r2 = (Road) Globals.map.roads.get(self.getRoadIdx());
p2 = (Point) r2.points.get(self.getPointIdx());

//refresh the FV
if(GPSutil.distance(p1, p2) <= this.FVehicleDistance &&
self.getRoadIdx()==sc.getRoadIdx() && self.getDirection()==sc.getDirection()
self.getLane()==sc.getLane())
{
switch(self.getDirection())
{
case 1: if(sc.getPointIdx()>self.getPointIdx())
{
this.FVehicle=sc;
this.FVehicleDistance=GPSutil.distance(p1, p2);
Globals.CUMMULATIVE_PACKETS_FV++;
Globals.IRT_FV+=this.currentTimethis.lastIRTFV;
this.lastIRTFV=this.currentTime;
return;
}
break;
case 0 :if(sc.getPointIdx()<self.getPointIdx())
{
this.FVehicle=sc;
this.FVehicleDistance=GPSutil.distance(p1, p2);
Globals.CUMMULATIVE_PACKETS_FV++;
Globals.IRT_FV+=this.currentTimethis.lastIRTFV;
this.lastIRTFV=this.currentTime;
return;
}
break;
default: break;
}

73

&&

if(this.FVehicle==null)
return;

//refresh the NFV

if(this.FVehicle.getVehicleId()!=sc.getVehicleId() &&
GPSutil.distance(p1, p2) <= this.NFVehicleDistance &&
self.getRoadIdx()==sc.getRoadIdx() && self.getDirection()==sc.getDirection() &&
self.getLane()==sc.getLane())
{
switch(self.getDirection())
{
case 1: if(sc.getPointIdx()>self.getPointIdx())
{
this.NFVehicle=sc;
this.NFVehicleDistance=GPSutil.distance(p1, p2);
Globals.CUMMULATIVE_PACKETS_NFV++;
Globals.IRT_NFV+=this.currentTimethis.lastIRTNFV;
this.lastIRTNFV=this.currentTime;
}
break;
case 0 :if(sc.getPointIdx()<self.getPointIdx())
{
this.NFVehicle=sc;
this.NFVehicleDistance=GPSutil.distance(p1, p2);
Globals.CUMMULATIVE_PACKETS_NFV++;
Globals.IRT_NFV+=this.currentTimethis.lastIRTNFV;
this.lastIRTNFV=this.currentTime;
}
break;
default: break;
}
}
}
//calculates the LAV and the RAV
private void calculateLCAVehicles(CarInfo self,CarInfo sc)
{
Road r1,r2 = null;
Point p1,p2 = null;
r1 = (Road) Globals.map.roads.get(sc.getRoadIdx());
p1 = (Point) r1.points.get(sc.getPointIdx());
r2 = (Road) Globals.map.roads.get(self.getRoadIdx());
p2 = (Point) r2.points.get(self.getPointIdx());
//refresh the LAV and RAV
if(self.getRoadIdx()==sc.getRoadIdx() &&
self.getDirection()==sc.getDirection() && self.getLane()!=sc.getLane() &&
Math.abs(self.getPointIdx()-sc.getPointIdx())<=1)
{
if(sc.getLane()==self.getLane()+1 &&
GPSutil.distance(p1,p2)<this.LAVehicleDistance)
{
this.LAdjancedVehicle=sc;

74

this.LAVehicleDistance=GPSutil.distance(p1,p2);
Globals.CUMMULATIVE_PACKETS_LAV++;
Globals.IRT_LAV+=this.currentTime-this.lastIRTLAV;
this.lastIRTLAV=this.currentTime;
return;
}
if(sc.getLane()==self.getLane()-1 &&
GPSutil.distance(p1,p2)<this.RAVehicleDistance)
{
this.RAdjancedVehicle=sc;
this.RAVehicleDistance=GPSutil.distance(p1,p2);
Globals.CUMMULATIVE_PACKETS_RAV++;
Globals.IRT_RAV+=this.currentTime-this.lastIRTRAV;
this.lastIRTRAV=this.currentTime;
}
}
}
}

CarRunningDSRC class :
public class CarRunningDSRC extends CarRunningVITP
{
private WirelessPhy physicalLayer;
private MAC80211 macLayer;
private Application appLayer;
public CarRunningDSRC(int vehicleId, byte lane, double speed,
short roadIdx, short pointIdx, byte direction, double offset)
{
super(vehicleId, lane, speed, roadIdx, pointIdx, direction, offset);
this.physicalLayer=new WirelessPhy(0);
this.macLayer=new MAC80211(0);
this.appLayer=new Application();
}
public void onReceive(byte[] bytesReceived, Communicator sender)
{
if (!isEquipped || bytesReceived == null)
return;
//System.out.println("on receive:"+bytesReceived[0]);
byte header = bytesReceived[0];
byte[] message = null;
switch(header)
{
case Globals.PROT_EMERGENCY:
this.appLayer.EmergencyVehicleWarning(bytesReceived,((CarInfo)this));
break;
default:super.onReceive(bytesReceived,sender);
}

75

}
public byte[] prepareMessage(int messageType)
{
if (!isEquipped)
return null;
byte[] bytesToSend=null;
//System.out.println("prepare:"+messageType);
if(messageType==-1)
{
byte[] localinfo = toBytes();
ByteArrayOutputStream outBytes = new ByteArrayOutputStream();
outBytes.write(Globals.PROT_EMERGENCY);
outBytes.write(CRTDIR);
try{
outBytes.write(localinfo);
}catch(IOException e){
}
bytesToSend = outBytes.toByteArray();
return bytesToSend;
}
else
{
return super.prepareMessage(messageType);
}
}
}

76