APPROVED: Ram Dantu, Major Professor Mark A. Thompson, Committee Member Pradhumna Shrestha, Committee Member Barrett R. Bryant, Chair of the
Department of Computer Science and Engineering
Hanchen Huang, Dean of the College of Engineering
Victor Prybutok, Dean of the Toulouse Graduate School
BSM MESSAGE AND VIDEO STREAMING QUALITY COMPARATIVE
ANALYSIS USING WAVE SHORT MESSAGE PROTOCOL (WSMP)
Htoo Aung Win
Thesis Prepared for the Degree of
MASTER OF SCIENCE
UNIVERSITY OF NORTH TEXAS
August 2019
Win, Htoo Aung. BSM Message and Video Streaming Quality Comparative
Analysis Using Wave Short Message Protocol (WSMP). Master of Science (Computer
Science), August 2019, 60 pp., 13 tables, 20 figures, 20 numbered references.
Vehicular ad-hoc networks (VANETs) are used for vehicle-to-vehicle (V2V) and
vehicle-to-infrastructure (V2I) communications. The IEEE 802.11p/WAVE (Wireless
Access in Vehicular Environment) and with WAVE Short Messaging Protocol (WSMP)
has been proposed as the standard protocol for designing applications for VANETs. This
communication protocol must be thoroughly tested before reliable and efficient
applications can be built using its protocols. In this paper, we perform on-road experiments
in a variety of scenarios to evaluate the performance of the standard. We use commercial
VANET devices with 802.11p/WAVE compliant chipsets for both BSM (basic safety
messages) as well as video streaming applications using WSMP as a communication
protocol. We show that while the standard performs well for BSM application in lightly
loaded conditions, the performance becomes inferior when traffic and other performance
metric increases. Furthermore, we also show that the standard is not suitable for video
streaming due to the bursty nature of traffic and the bandwidth throttling, which is a
major shortcoming for V2X applications.
Copyright 2019
by
Htoo Aung Win
ii
TABLE OF CONTENTS
Page
LIST OF TABLES vi
LIST OF FIGURES vii
CHAPTER 1 INTRODUCTION 1
1.1. Introduction and Background 1
1.2. Motivation 2
1.3. Background 3
1.3.1. Vehicular Ad-Hoc Network (VANET) 3
1.3.2. Wireless Access in Vehicular Environment (WAVE) 6
1.3.3. IEEE 802.11p 7
1.4. Thesis Statement 7
1.5. Problem Definition 7
1.6. Outline of Thesis 8
CHAPTER 2 STANDARDS AND PROTOCOLS 9
2.1. Vehicular Ad-Hoc Networks (VANET) 9
2.2. Wireless Access in Vehicular Environment (WAVE) Protocol Stacks 11
2.3. WAVE Physical Layer (IEEE 802.11p) 12
2.4. WAVE Medium Access Control Layer (IEEE 802.11 & 1609.4) 14
2.5. Logical Link Control Layer (IEEE 802.2) 14
2.6. Network and Transport Layer (IEEE 1609.3 WSMP) 15
2.7. Summary 16
CHAPTER 3 DESIGN AND IMPLEMENTATION OF VANET 18
3.1. Device Information and Setup 18
3.2. Implementation 20
3.2.1. Application Architecture 20
iii
3.3. TCP/IP Setup for Video Streaming Application 24
3.4. WAVE Stack for Both Applications 26
3.5. Variables and Implementation Constraints 30
3.5.1. Recorded and Calculated Variables 30
3.5.2. Constant Variables 30
3.5.3. Experimental Constraints 30
3.6. Experimental Setup 30
3.6.1. BSM Application 33
3.6.2. Video Streaming Application 33
3.7. Summary 34
CHAPTER 4 PERFORMANCE, RESULTS, AND ANALYTIC 36
4.1. Distance and Performance Metrics 38
4.1.1. Distance vs Delay 38
4.1.2. Distance vs Bitrate 40
4.1.3. Distance vs Packet Loss 41
4.1.4. Distance vs Performance Metrics Summary 42
4.2. Speed and Performance metrics 43
4.2.1. Speed vs Delay 43
4.2.2. Speed vs Bitrate 45
4.2.3. Speed vs Packet Loss 46
4.2.4. Speed vs Performance Metrics Summary 47
4.3. Transmission Rate 48
4.3.1. Transmission Rate : 1 ms 48
4.3.2. Transmission Rate : 20 ms 50
4.3.3. Transmission Rate : 50 ms 52
4.4. Summary 53
CHAPTER 5 CONCLUSION AND FUTURE WORK 54
iv
5.1. Limitation 55
5.2. Future Work 55
5.3. Summary 56
REFERENCES 58
v
LIST OF TABLES
Page
Table 1.1. VANET Terminology 5
Table 2.1. VANET Characterstics [7] 10
Table 2.2. WME Function Summary 16
Table 3.1. ARADA Devices Quick Summary 19
Table 3.2. Recorded and Calculated Variables 31
Table 3.3. Constant Variables 32
Table 3.4. Experiment Constraint 32
Table 4.1. List of Experiments 37
Table 4.2. Distance Experiments Summary 43
Table 4.3. Speed Experiments Summary 47
Table 4.4. Transmission Rate: Experiment Parameters 49
Table 5.1. Feasible Applications for Implementation [14] 54
Table 5.2. Future Work Related to this Project 56
vi
LIST OF FIGURES
Page
Figure 1.1. VANET Overview 4
Figure 1.2. WAVE Protocol Stack 6
Figure 2.1. WAVE Stack [3] 12
Figure 2.2. Channel in WAVE Stacks 13
Figure 2.3. WSM Header [5] 17
Figure 3.1. Hardware Setup: Devices 20
Figure 3.2. Hardware Setup: Vehicles 21
Figure 3.3. Overview BSM Application 22
Figure 3.4. Overview Video Streaming Application 23
Figure 3.5. Route taken for testing BSM Application 34
Figure 3.6. Route taken for testing Video Streaming Application 35
Figure 4.1. Distance vs Delay 39
Figure 4.2. Distance vs Bitrate 40
Figure 4.3. Distance vs Packet Loss in Percentage 42
Figure 4.4. Speed vs Delay 44
Figure 4.5. Speed vs Bitrate 45
Figure 4.6. Speed vs Packet Loss in Percentage 47
Figure 4.7. Delay for Packets at Transmission Rate (1ms) 50
Figure 4.8. Delay for Packets at Transmission Rate (20ms) 51
Figure 4.9. Delay for Packets at Transmission Rate (50ms) 52
vii
CHAPTER 1
INTRODUCTION
1.1. Introduction and Background
Dedicated short range communication (DSRC) was first introduced by the Federal
Communications Commission (FCC) in 1999 [8] to allocate a spectrum dedicated for com-
munications between transportation systems and vehicles. It has been in research since for a
real-world implementation for intelligent transportation systems (ITS) [9]. Due to the nature
of DSRC, it is considered a best-suited technology to implement vehicle-to-vehicle (V2V) or
vehicle-to-infrastructure (V2I) communications. Network infrastructure built upon vehicu-
lar communications is called vehicle ad-hoc networks (VANETs). VANETs are specifically
designed to support the implementation of safety applications, driving assistant applications,
and infotainment for vehicles in the high-speed environment. There are several factors in
VANETs that need consideration, such as ever-changing network topology, a very small time-
frame for handshakes, and minimum packets delay and loss in a fast moving environment
[13].
There is a standard recently established to meet all the requirements criteria for
VANETs. It is called 802.11p/Wireless Access in Vehicular Environment(WAVE). This
standard must be tested for different scenarios for different application purpose under dif-
ferent conditions. Only with thorough testing, a conclusion can be drawn and can proceed
with the standards for implementing and designing applications for the VANET.
Most of the research in V2V communications are done via simulation and analytical
means [10, 12, 17] along with some very constrain real-world analysis research papers [20, 19].
The results between the simulation and the actual real-life implementations are different. The
goal of this thesis is to perform experiments on the communication standard for two main
different application types - basic safety messages (BSM) application and standard basic
video streaming application using the most common codec (such as MP4) under different
kind of conditions (variables). This is a desirable research area in order to support the
1
current existing Internet Communications standards.
For this paper, two devices from ARADA Systems are used for the testing purposes.
These devices are equipped with latest 802.11p Standard Radio Chip and support Wireless
Access in Vehicular Protocols (WAVE) stack which makes use of WAVE Short Message Pro-
tocol (WSMP). WSMP has its own messaging format called WAVE Short Messages (WSM)
which this paper will be focusing to experiment with WSM by performing experiments with
a different type of application. For all the experiments in this paper, certain basic metrics
will be recorded using hardware sensors and GPS. Some of the basic metrics are recorded
and logged on the device itself such as GPS, Wave Short Messages (WSM). These basic
metrics are in turn used for calculating other performance metrics such as, in the case of
video streaming, distance and a relative speed between two cars.
Experiments in this paper are performed for two distinctly different application type:
video streaming application, and BSM message. Both of the experiments set are recorded in
an open field with almost little to no traffic. The details of the design and implementation
of the VANET are discussed in Chapter 3. These recorded data in the different environment
will then be analyzed for delays, jitters, and packet loss which will be measured against
relative velocity and distance. All the results will be discussed in Chapter 4.
1.2. Motivation
Every year, there are increased in number for people using vehicles as their main
method of travel. Due to the enormous increase in commuting by vehicles, traffics on the
road has become much more congested. This lead to an increase in the number of car
accidents being reported each year and has been gradually increasing every year. Intelligent
Transportation System (ITS) was designed and proposed to ease these number of incidents [1]
by implementing safety measures on the vehicles itself as well as to provide communication
between vehicles for other purposes such as infotainment. There are several numbers of
research on implementing safety assistant application, as well as other types of application,
for ITS.
One of the research areas is in smart vehicles technologies. Sensors are implemented
2
on vehicles for the vehicle to be aware of its environmental hazards and to assist drivers with
environmental information. Currently, it is being implemented on each individual vehicles
and not being implemented as a system itself. This causes fragmentation in the automobile
industry. It is also known to be implemented on the higher-end vehicle model, hence the
availability and affordability of these vehicles are very limited. Smart vehicle technologies
are being invested by industry giants such as Google, Tesla, BMW, Mercedes, and so forth.
Even though public perception of this technology is very positive for younger generation [18],
there are no system in place for the connected vehicles.
Another field of research is invested in connected vehicles. Entities, like US Depart-
ment of Transportation (USDOT), are pushing for communication between vehicles and the
surrounding environment to manage and improve traffic flow through traffic algorithms. This
will allow the implementation of smarter traffic collectively. Smart traffic is being defined as
a system able to provide vehicles with the necessary information to vehicles and its drivers
to have smoother and less congested traffic overall [16]. This technology will change the way
of commuting as we know it as it will also provide infotainment applications to passengers
on a vehicle. Both fields have progressed to a certain extent where eventually, both field will
merge together to implement for better traffic management, contributing to a better ITS.
This paper is focused on the latter: to test out the V2V communications standard for
the performance of safety message application and infotainment application. This paper will
be focused on WAVE protocol stacks and 802.11p radio standard and experimenting with
WSM, as it is considered as the defacto standard in V2V communications [17].
1.3. Background
1.3.1. Vehicular Ad-Hoc Network (VANET)
Vehicular Ad Hoc Network (VANET) is a network consist of direct communication
between Vehicles-to-Vehicles(V2V) and/or Vehicles-to-Infrastructures(V2I). It is a big part
of ITS implementation. Figure 1.1 describe the overview of VANET and Table 1.1 describe
some of the most common VANET terminology.
3
Figure 1.1. VANET Overview
There are components in VANET as shown in Figure 1.1. Each of the components is
listed in Table 1.1 which define the terminology. These common terminologies will be used
throughout this paper.
VANET is a distributed peer-to-peer network with constant changing network topol-
ogy. The constant changing of network topology is caused by moving vehicle with high speed
at any given time due to the fact that each vehicle capable of communication are considered
as an individual node. The topology of network edges will not change due to Roadside Unit
(RSU) having to be set up permanently by hardware vendors on the roadside as a part of
VANET infrastructure.
The communications between each node allow implementations of rich applications
4
Terminology Description Example
Vehicular Ad-hoc
Network
A network make up of several vehicle carrying V2V/V2I
communication devices such as RSU and OBU where
RSU are the edges of the network and OBU are the nodes
of the network.
County, highway,
commercial area
Roadside Unit (RSU)
RSU are the edges of the network, sitting at the edge of
the network, connected by nearest nodes in a range. It
can communicate with other interfaces such as WiMAX
/3G, Ethernet, and others.
Cell towers, base
station, buildings
Onboard Unit (OBU)
OBU are the nodes of the network, where each nodes
are connected to each other and the nodes closest to
the edge of the network are connected to the edge as
well. They are inter-connected in a VANET.
Any form of
automotive
Vehicle to Vehicle
communication (V2V)
A connection between nodes are called V2V
communication.
Car to car, truck
to car
Vehicle to Infrastructure
communication (V2I)
A connection between a node and an edge is
called V2I communication.
Car to cell tower,
base station to truck
Table 1.1. VANET Terminology
for vehicles, drivers, passengers, and network/traffic controllers. Each individual node can
access data from other surrounding nodes for safety or entertainment purpose. Since the
nature of the nodes are not powerful and having limited storage spaces, these nodes can
offload data to RSUs. The RSUs/edges of the VANET can provide more data and services
to the nearby nodes.
When all these components are together in a set of defined space, such as a county
or residential neighborhood, the area will have a support of VANET. Areas that are set up
for VANET will be able to provide services to the vehicles in the network with safety and
infotainment applications. This paper made focuses on communication devices specifically
designed to use for VANET to take measurement and record performance metrics between
safety message and video streaming performances. A standard is established by IEEE for
5
VANET, which is called WAVE stack.
1.3.2. Wireless Access in Vehicular Environment (WAVE)
Wireless Access in Vehicular Environment (WAVE) is a set of standards established
by IEEE for implementing VANET. WAVE make use of a Dedicated Short-Range Communi-
cation (DSRC) technology to provide a high-speed V2V and V2I data transmission. WAVE
is a major application to a solution to an ITS [15]. Figure 1.2 define all the layers of WAVE
stack. The details of each layer are explained in details in Chapter 2. Figure 1.2 portray
the general overview of full WAVE stack and it is made up of Management Plane and Data
Plane.
Figure 1.2. WAVE Protocol Stack
Management plane is unique to WAVE which consists of Wave Management Entity
(WME) which handle configurations, frames management, and service advertisement. The
configuration manages operations in for frames and channels. The data plane consists of
exchanging data using WAVE short message protocol (WSMP). The rest of the stack is
similar to that of the OSI model.
6
This paper performed and designed experiment by understanding and making use
of WAVE stack. The different type of applications for a different set of experiments is
configured in WAVE stack to accommodate the nature of the application. By properly
configuring the WAVE stack, it can be used for different type of applications based on the
application requirements.
1.3.3. IEEE 802.11p
In WAVE stack, IEEE is currently working on a new amendment 802.11p which is
based on IEEE 802.11 family of radios. IEEE 802.11p is a DSRC aims to address all the
issue that the traditional 802.11 radio faces. The difference between traditional 802.11 family
of radios and 802.11p is that 802.11p accommodate the data transmission for a high-speed
environment. Chapter 2 explained more in details about IEEE 802.11p standards.
The devices used in this paper for communication are the IEEE 802.11p radio chip.
This paper focuses on Application Layer and Management plane of the WAVE stack so we
will not be focusing much on IEEE 802.11p radio standards.
More of the VANET, WAVE, and 802.11p details are discussed in Chapter 2.
1.4. Thesis Statement
Is there a performance difference between for BSM application and different appli-
cation messages, such as video streaming applications, using WSM as a communication
protocol? This thesis is about performance analysis of IEEE 802.11p radio capabilities, in
combination with WAVE stack, using WSM as the main form of message for a different type
of application in contrast of each other by nature. Experimenting the standard under dif-
ferent conditions for the different type of application will draw a conclusion for a real-world
V2V and/or V2I communications for the application.
1.5. Problem Definition
As smart car technologies are emerging rapidly, big companies such as Google, Tesla,
and the U.S. Department of Transportation starts to look into the advancement of this field.
To be considered as a connected vehicle with smart traffic accommodation, communication
7
between vehicle is a critical feature. To have the communication established, IEEE amend-
ment one of their standard 802.11 radio to IEEE 802.11p which is specifically issued for
smart transportation requirements.
The nature of communication between vehicles can be of anything. It can vary from a
very simple transmitting short messages or bursting streams of packets in a video streaming
nature. Depending on the type and nature of the applications, the requirement for each
application is varied. For these reasons, a comparison in performance for a standard is
needed to test for comparison between two applications.
In this paper, a recent new standard was tested to see if theoretical values reflect
the actual real-world implementation. Experiments to find these metrics are performed by
testing using different parameters and type of application for a conclusive and comparative
result.
1.6. Outline of Thesis
This thesis is focused on performing a field analysis of the IEEE 802.11p radio in
combination with WAVE stack, particular of WSM capabilities, to come to conclusive and
comparative results. The conclusion will be a comparative result of a different application
on top of V2V/V2I communications in a real-world scenario. Chapter 2 focuses on details
of VANET, WAVE stack and IEEE 802.11p radio standard. Chapter 3 talked about the
design and implementation of the system to perform this experiment. Chapter 4 is the
result and comparison of data with analytic for different metric and is the crux of this thesis.
Conclusion and future works are discussed in Chapter 5.
8
CHAPTER 2
STANDARDS AND PROTOCOLS
2.1. Vehicular Ad-Hoc Networks (VANET)
Vehicular Ad-Hoc Network (VANET) is a self-organizing network that integrates the
capabilities of a new generation of wireless networks to support communication between
Vehicles-to-Vehicles (V2V) and Vehicles-to-Infrastructures (V2I). VANETs can make use
of any tools to provide communication such as IEEE 802.11 b/g, WiMAX, IEEE 802.10,
Bluetooth and so on [7]. It recently became popular as smart vehicle started to become more
accessible for consumers. Smart vehicles are part of ITS progression and the next step in
ITS is communication between vehicles. VANET opens up many vehicular applications such
as safety applications, consumers directed applications, entertainments related applications,
and traffic management application. There are certain characteristics for a network to be
considered a VANET as stated in Table 2.1.
Like all other network types, VANET consists of several nodes and edges. VANET
consider each vehicle as an individual network node and roadside base station devices as
network edges or sink. The difference between VANETs and a traditional network is that
VANETs has a constantly changing network topology due to vehicles in a fast-moving en-
vironment. The rate of changes in network topology is extremely high and not considered
as a static network topology [4]. This also applies to the fact that VANET has a dynamic
network size as well as variable network density depending on the traffic on the road. This
call for a new thinking of implementation of VANET.
In VANET, each individual car act as an individual router/node. In a typical high-
way VANET scenario, there are several moving vehicles on a highway with communicating
capabilities between each other or with road-side infrastructure. The communication units
on these vehicles are known as On-Board Unit (OBU) and the communication units on the
roadside are known as Roadside Unit (RSU). The difference between OBU and RSU is that
RSU has more powerful components and more interface for extra connectivity whereas OBU
9
Characterstics Description
MobilityEach nodes in VANETs move at a very high
speed.
Changing Network
Topology
Each nodes moving rapidly in VANETs
causes network topology to change as well.
No power constraintsThere are no power constraints as each node
will be provided by a vehicle it’s on.
Dynamic Network
Size
Network size is unbounded as it can be
generated dynamically as needed.
Demanding Time
Time to deliver a message is very critical since
each nodes can have a very short association
time.
Wireless CommunicationEach nodes are connected through reliable
wireless communication.
Variable Network DensityNetwork density is varied according how many
vehicle/nodes in VANET at any given moment.
Table 2.1. VANET Characterstics [7]
is a simple unit that is just capable of simple communication. RSU also act as the edges
of the network topology which can route packets to the internet for any services that they
might need.
Since VANET allow communication in a fast-moving environment, there are a set of
standards implemented for VANET. The most important factor in VANET is the association
time between units. Due to the nature of the high-speed environment, a node in the network
cannot afford a long association time to start communicating with each other. This is one
of the most crucial factors in implementing VANET [13]. Traditional IEEE standard does
not accommodate well for this kind of scenario since it requires time for association and
10
handshake which VANET cannot afford. Addition to those criteria, there are some other
criteria to meet as a requirement for VANET.
VANET need to have a minimal packet loss during transmission. Due to the high-
speed environment, the connection cannot afford packets loss. Anything greater than 5%
packet loss will create an issue in application performances [6]. This is critically needed for all
kind of applications where a delay and packet arrival rate are of utmost importance. Packet
loss in peer-to-peer video streaming application can affect video performance [2] where the
video would appear jittery and lose in quality. Along with those, the delay time for an
inter-packet arrival must be at a reasonable rate and not much tolerated. A packet must
arrive between 1ms to 20ms to 100ms for application to function properly [14]. Anything
out of range will create complications for all kind of safety and entertainment applications.
The variance in delay for the arrival of packets, also called jitters, is also an important
factor for infotainment applications. Depending on the type and nature of the application,
the tolerance level differ. Safety applications such as broadcasting safety messages and
traffic messages cannot tolerate jitter, while applications for infotainment and consumer
advertisement can tolerate up to certain extend.[11]
Finally, the interface used in the physical layer must able to meet the requirement of
being able to hold communications for the variable speed and velocity of a moving vehicle.
It is one of the most crucial factors since the other critical requirements depend on this layer.
Hence IEEE 802.11p was proposed to tackle these problems posed by traditional networks.
2.2. Wireless Access in Vehicular Environment (WAVE) Protocol Stacks
Due to traditional radio coming up short with the requirements, IEEE propose a
standard that will address all these issues which are known as Wireless Access in Vehicular
Environment (WAVE) protocol stack. The stack aim was to tackle inter-vehicle communi-
cation requirements, to unified standards, and to implement said standard protocols. IEEE
came up with new radio standards: IEEE 802.11p to address all the shortcoming of the
traditional 802.11 a/b/g/n radio in the vehicular environment. Based on IEEE 802.11p ra-
dio using as a physical layer, WAVE technology was proposed as a solution to Intelligent
11
Transportation Systems (ITS). WAVE stack is defined in Figure 2.1.
Figure 2.1. WAVE Stack [3]
Figure 2.1 shows all the layer in WAVE stack. There are several components that
make up the WAVE stack. The following section is the detail of each layer of the WAVE
stack.
2.3. WAVE Physical Layer (IEEE 802.11p)
IEEE 802.11p is used as the physical layer of in WAVE stack. IEEE 802.11p radio
uses 5.700Ghz to 5.925Ghz frequencies with 10MHz and 20MHz channel bandwidth. IEEE
802.11p, the amendment to IEEE 802.11 family of radio, is the IEEE standard to establish
communication between high-speed vehicles.
IEEE 802.11p uses Orthogonal Frequency Division Multiplexing (OFDM) scheme,
similar to IEEE 802.11a radio, and has the same physical layer design. The difference
between IEEE 802.11a and IEEE 802.11p is that IEEE 802.11p uses 10Mhz as overall band-
width whereas IEEE 802.11a uses 20MHz. IEEE 802.11p can use 20Mhz by combining two
bandwidth next to each other. There are seven 10Mhz channels where six of the channels are
12
service channels and one of them is the control channel. Figure 2.2 shows different channels
defined for WAVE stack for multi-channel operation in VANET.
Figure 2.2. Channel in WAVE Stacks
There are two types of channels: Service Channels (SCH), and Control Channels
(CCH). Control Channels (CCH) is reserved for system management messages such as WAVE
Service Advertisement (WSA) and security applications with intend to control information.
Service Channels (SCH) are used for general-purpose applications and may be coordinated
via a WSA. From figure 2.2, 10 MHz channels (SCH unless otherwise stated) are of channel
number 172, 174, 176, 178 (CCH), 180, 182, 184. Designated Channels for Safety of Life and
Property are 172 and 184. Each channel has a unique integer value that is associated with
a service being provided by DSRC WAVE. The unique integer is known as Personal Service
Identifier (PSID).
Personal Service Identifier (PSID) for each channel range from 0 to 270,549,119 on
any channels which act as a form of identification. In theory, each channel can have a PSID
channel ranging from 0 to 270,549,119 and since we have 7 usable channel (including control
13
channel) we have around 1.89 billion usable PSID for each channel.
Theoretically, IEEE 802.11p can communicate with a distance up to 1000m, both in
V2V and V2I modes with a relative speed up to 30 m/s (67 MPH) under different envi-
ronment provided that there is a line-of-sight. 10Mhz bandwidth have a theoretical bitrate
between 3 and 27Mbps, whereas 5Mhz or 20MHz bandwidth channel has bitrate between
13.5 Mbps and 54 Mbps.[15]
Since IEEE 802.11p is different from traditional 802.11 in a sense that IEEE 802.11p
cannot afford authentication and association in MAC and PHY layers due to very limited
time constraint. Unlike 802.11 Basic Service Set (BSS), WAVE has its own Wave BSS
(WBSS) which let node communicate each other before any authentication or association as
long as the node has received a WBSS announcement from WBSS provider. To keep the
network synchronized, a channel is divided into 100ms intervals. Each interval has SCH and
CCH alternatively with a guard band. This keeps the network synchronized.
2.4. WAVE Medium Access Control Layer (IEEE 802.11 & 1609.4)
To support multi-channel operations, WAVE stack uses (which this experimentation
is also based on) 1609.4 – Multi-Channel Operations which provides enhancements to IEEE
802.11 Media Access Control (MAC). The 1609.4 standards are used is a revision of 1609.4-
2006 standard. Due to the nature of WAVE stack, 1609.4 layer is needed since WAVE
do have different channels and 1609.4 accommodate to it. Implementation of IEEE 1609.4
allows the stack to have prioritization, routing, and coordination of channels.
2.5. Logical Link Control Layer (IEEE 802.2)
IEEE 802.2 is the original standard of IEEE for Logical Link Layer (LLC) and provide
a uniform interface to the user of the network layer. Since it is compulsory for all IEEE
802 networks to use LLC, WAVE stack adopted 802.2 as the default standard. 802.2 LLC
complement MAC and PHY in a way that the channel routing service controls the routing
of data packets from LLC to the designated channel within channel coordination operations
in the MAC layer. LLC then proceed and send a delivery over the physical layer.
14
2.6. Network and Transport Layer (IEEE 1609.3 WSMP)
IEEE Std 1609.3 is the Networking Services for the of the WAVE stack which defines
network and transport layer services, including addressing and routing, in support of secure
WAVE data exchange. In WAVE stacks, 1609.3 provide two main networking services: data
plane services to carry traffic and Management-plane services to configure and maintain
traffic.
For data-plane service, WAVE architecture support two forms of protocol stacks:
Wave Short Messaging Protocol (WSMP) and traditional IPv6 and can be used interchange-
ably.
WSMP is a proprietary protocol of WAVE stack and is only valid for WAVE archi-
tecture and is not valid for other traditional radio waves. WSMP is a priority come-first
protocols that enable the application to send short messages and directly control certain pa-
rameters of the radio resource to maximize the probability that all the implicated parties will
receive the message in time. Since WSMP is a proprietary protocol, Internet applications do
not support it and it purely depends on private investment in implementing it. Hence the
inclusion of IPv6 which existing standards support.
The inclusion of IPv6 let WAVE stack let it interacts with pre-existing Internet appli-
cations and does not need special privileges. However, IPv6 was included for more traditional
and less demanding exchanges such as Transmission Control Protocol/User Datagram Pro-
tocol (TCP/UDP) when time restriction and packet priority is of not of that importance.
For management-plane service, WAVE stack uses IEEE 1609.3 standard collectively
known as Wave Management Entity (WME). WME consist of: Application registration,
WBSS management, channel usage monitoring, IPv6 configuration, received channel power
indicator monitoring, and management information base (MIB) maintenance. The followings
are the summary of each function.
As stated above, there are two communication protocols - IPv6 and WSMP. In this
paper, we will be focusing on WAVE Short Message (WSM) which, unlike IPv6 which may be
only sent on SCH, which allows the application to directly control PHY layer characteristic.
15
Name Summary
Application Registration
It is needed for all applications that uses WAVE networking
services and must register WME. Registration information are
recorded in three tables.
Provider Service Info List of applications that provide a service
User Service InfoGive information about applications residing in the local
network that are interested in the provided service.
Application StatusShow and maintain the status of each application in a
context of WBSS.
Channel Usage MonitoringMonitor channel usage of WME which keep tracks of service
channels usage patterns.
IPv6 Configuration For managing the IPv6 related information.
RCPI Monitoring It manages the strength of the received signal from a remote device.
MIB Maintenance
It maintain management information containing system-related
(router, gateway, DNS, etc..) and application-related(provider service info,
user service info, and application status) data.
Table 2.2. WME Function Summary
Figure 2.3 show the current version of IEEE 1609.3 WSM header definition.
As you can see in Figure 2.3, the application can directly control the header field
which heavily makes use of it in this paper. By setting the header correctly, WSM packet
can be configured for the different application type.
2.7. Summary
In this Chapter, we expanded more on several standards and protocols that were used
in this paper. We went into details of VANET about its characteristics and requirements. We
also went over how VANET treat each component and how it is different from other types
of network. After that, we went over WAVE stack in details that accommodate VANET
16
Figure 2.3. WSM Header [5]
requirements. Details of each layer in the WAVE stack were expanded in details to fit the
requirements for our experiments.
17
CHAPTER 3
DESIGN AND IMPLEMENTATION OF VANET
To have a conclusive and comparative result for WSM performance for different appli-
cation type, the setup and implementation must be designed optimally to record the targeted
metric while meeting the minimum requirements using specific channels and parameters. The
setup was designed and implemented to accommodate two kinds of applications performed
for this paper: Basic Safety Messaging (BSM) messaging application and Video Streaming
application.
The setup includes a device capable of using 802.11p DSRC radio and support WAVE
standard with a support run custom code. The aim of the custom code is to run a full
suite of test that collects following metrics from both applications: packet delay, jitters,
bandwidth, distance, and speed of a device during the experimentation. Some metrics for
Video Streaming application are recorded by Wireshark network protocol analyzer for more
detail analysis.
The experiment uses two devices supported with 802.11p and WAVE stack: ARADA
MINI2 and ARADA Locomate Roadstar from ARADA Systems of Lear Corporation. The
devices support all the required standards and interfaces needed to perform experiments.
3.1. Device Information and Setup
For this experiment, we have two different devices from ARADA Systems that support
WAVE stack and is compliant with IEEE 802.11p standards. Both devices are capable of
sending and receiving WSMP and IPv6 messages. The main differences between the devices
are that one of the devices is to operate as an OBU, namely Arada Mini2, whereas the
other device is to operate as RSU, namely Arada Roadstar. Both devices are capable of
communication with each other. Table 3.1 shows the summary of both devices capabilities.
The devices can be set up in a different configuration, namely Provider configuration
and User Configuration. There is some difference between the two configurations. Provider
configuration is mainly used to send data transmission while User configuration mainly allows
18
Device Quick Summary
WAVE Standards Support: 802.11p, 1609.2, 1609.3, 1609.4, SAE J2735, VAD/CAMP
5.7 to 5.925 GHz frequencies
10 MHz and 20 MHz channel bandwidth
Integrated DSRC, GPS, Bluetooth and CPU
Support for WAVE data and management frames.
CCH for broadcast, high-priority and single-use safety messages and SCH for IP data.
Table 3.1. ARADA Devices Quick Summary
to receive the data transmission. Both the devices from ARADA are set up for Provider
and User mode in order to allow both transmission and reception. modes It was set up with
the same configuration to eliminate the performance metrics differences due to a different
configuration.
Figure 3.1 shows how the hardware is set up in each vehicle for the experiment. Each
component of the setup is clearly labeled. There are two variations of V2V devices which
are connected to a laptop and their own version of an external antenna. MINI2 uses two
separate normal WSM antenna and one external GPS antenna. Roadstar uses a Sharkfin
Antenna, which is a unit that combines three WSM antenna and one GPS antenna in it.
Regardless of antenna variation, their functionality remains the same.
Figure 3.2 shows how the experiment is generally set up for the experiments. Each
device is mounted on two separate vehicles where one vehicle act as a broadcaster and
another vehicle act as a receiver. In each vehicle, it has it’s own setup as shown in Figure 3.1
where each person on each vehicle keep watch on the experiment application running and
communicate with each other through a telephone. This was how all the experiments were
performed.
19
Figure 3.1. Hardware Setup: Devices
3.2. Implementation
3.2.1. Application Architecture
In order to test the performance metrics between BSM messaging application and
Video Streaming application, the setup is specifically designed in a way to complement
applications for their own purpose. Figure ?? shows the general structure in BSM application
and Figure 3.4 shows the overall Video Streaming application architecture.
In designing the application architecture for Video Streaming application, as shown
in Figure ??, MINI2, and Roadstar are running the same executable code and exchanging
simple WSM messages with high priority flag on in WME. The WME configuration variable
for both the devices are the same.
First, when the application starts, all of the parameters are set for the experiments.
The parameters are taken through the application’s arguments. Those variables are for
20
Figure 3.2. Hardware Setup: Vehicles
WME setup and flag such as transmission rate, buffer size, channel, and PSID.
After all the necessary parameters are set, the GPS object was initiated through
the library call. The library was provided by Lear Corporation in their SDK. The GPS
object contains all the GPS data, e.g. latitude, longitude, speed, etc., which was needed for
calculating performance metrics. Those data were logged as necessary in the experiments.
DOT3 connection was established after GPS initiation. DOT3 connection establishes
a connection to the lower level of the WAVE stack which define WME and WSM interface
ports. This is needed for the physical layer. For all the experiments, it defaults to the
device’s default port 127.0.0.1. This connection was used in calling Library 1609.3 in order
21
Figure 3.3. Overview BSM Application
labelfig:bsmApp
for us to request channel access for WSM.
MINI2 generate an object which is made up of a string constructed from the GPS
variable. After the object is created, the object is then converted into WSM message which
got transmitted out to pre-defined channel and PSID.
On another device, Roadstar, it is running the same executable code but instead of
generating a payload and transmitting, it listens and decode the incoming message on a
given channel and PSID. The decoded message is then shown on the screen. More details
22
are in Section 3.4.
Figure 3.4. Overview Video Streaming Application
In setting the parameters and initializing libraries for the video streaming application,
it is very similar to the BSM application setup. The only difference is how the WSM packets
are created.
23
Generating WSM messages in Video Streaming application is different compared to
BSM application. In implementing the application architecture for Video Streaming appli-
cation, as shown in Figure 3.4, laptop-A is a streamer which stream RTP packets, by using
VLC client, and tunneling all the packets to Arada MINI2. Arada MINI2 encode incoming
RTP packets received from the laptop into WSM packets. The WSM packets properties are
defined accordingly with predefined WME parameters, where more details are explained in
the WAVE stack subsection. Arada MINI2 transmit and busts WSM packets with the set
properties.
Arada Roadstar, where its WME properties are configured as same as Arada MINI2,
is on standby mode. Arada Roadstar is actively listening on a specific channel and PSID
defined by the WME, which is explained more in the WAVE stack subsection. Once Arada
Roadstar receives WSM packets, it decodes WSM packets into RTP packets and tunnel those
said packets to Laptop B through a specific port. Laptop-B is listening on a specific RTP
port for the incoming video stream, from a VLC client connected to the said port, where it
decodes all the packets into a video stream.
The connection between the V2V devices and laptops is a TCP/IP connection through
ethernet. The detail implementation of the TCP/IP connection between Arada devices and
laptops are explained more in Section 3.3.
3.3. TCP/IP Setup for Video Streaming Application
In the implementation of a V2V communication for Video Streaming application,
the video stream data need to be generated. VLC application, a well known Open Source
Media Player, is used as an application to stream video on a network. VLC can stream
video on the same network through User Datagram Protocol (UDP), Real-Time Protocol
(RTP), and HTTP for video streaming. For the experiment, RTP protocol is used since it
is used extensively in communication and entertainment systems. A Wireshark is attached
to both computers to keep a log of the packets going in and out of the socket for analysis
purpose. The following code snippets are code implemented for creating a socket for TCP/IP
connection.
24
Above code snippet shows the implementation of TCP/IP code on the transmitting
V2V device. In the implementation of the TCP/IP on the V2V for sending video stream,
the V2V device has a non-blocking port open for the video data stream connection. It has a
buffer size, which is the maximum buffer size for the WSM protocol, that will write to it as
data come in. It will then send it to a function where it encodes the said data stream into
WSM format and then transmitted it out. The transmission will be received by a receiver
that can decode the video data stream and output the display.
1 s t a t i c void rxWsmCallBack (p16093WSMData ∗wsmReqData)
2 {
3 i f ( packe tCont ro l l e r == 0)
4 {
5 rxInd = ( p16093WSMRxIndication ∗)wsmReqData−>data ;
6 i n t lengthOfDataBuffer = rxInd−>l ength − SEQ BUFFER LEN;
7 char buf [ lengthOfDataBuffer ] ;
8 memset ( buf , 0 , lengthOfDataBuffer ) ;
9 memcpy( buf , rxInd−>data , lengthOfDataBuffer ) ;
10 memcpy( packSeq , rxInd−>data + lengthOfDataBuffer , SEQ BUFFER LEN) ;
11 p r i n t f ( ”Datagram : %s \n” , packSeq ) ;
12
13 i f ( sendto ( sockfd , buf , lengthOfDataBuffer , 0 ,
14 ( s t r u c t sockaddr ∗)&server , s i z e o f ( s e r v e r ) ) < 0)
15 {
16 d i e ( ” sendto ( ) ” ) ;
17 e x i t (2 ) ;
18 } e l s e p r i n t f ( ”Sent\n” ) ;
19 i f ( ! locat ionSensorGetData(&locationCTX , &lData ) )
20 pr intAna lys i sLog ( f , packSeq , lData ) ;
21 e l s e
22 printAnalysisLogNoGPS ( f , packSeq ) ;
25
23 packe tCont ro l l e r = 1 ;
24 } e l s e
25 packe tCont ro l l e r = 0 ;
26 }
Above code snippet shows the implementation of TCP/IP code on the receiving V2V
device. In the implementation of the TCP/IP on the V2V for receiving the video stream,
the V2V device is always on a listening mode on a specific PSID and Channel. Once the
data come in from a specific PSID and Channel, it would receive the data stream and then
send it out to a specific port to a computer which decodes the video data stream and display
it on the screen.
3.4. WAVE Stack for Both Applications
WAVE standard has WAVE Management Entity (WME) in the management plane
of the WAVE stack where all the parameters for the WSM and the radio properties are
set. It manages and defines a transmission channel with QoS priorities and data frames are
scheduling, along with differentiating between emergency safety message and other messages.
WME also handle management of frame queuing, priority channels and handling of safety
messages. The object for WME is initiated before calling 16093 libraries.
The WME was initiated using the properties stated in Figure ??. It is a structure of
WME properties which hold all the properties of required variables such as PSID, channel
number, and data rate and payload length. Using the instance of WME, 16093 Library call
is initiated. Library 16093 is the standard which defines network and transport layer service,
such as addressing and routing along with the support of secure WAVE data exchange. The
following code snippet is the initiation of 1609.3 Library with a return code.
1 r e t = l i b 1 6 0 9 3 I n i t (&samplePriv−>wmeCtx , &samplePriv−>wsmCtx) ;
2 i f ( r e t != LIB SUCCESS) {
3 p r i n t f ( ” I n i t f a i l e r rno %d\n” , r e t ) ;
4 d e i n i t ( ) ;
26
5 re turn −1;
6 } e l s e {
7 p r i n t f ( ”DOT3 i n t e r f a c e i n i t i a l i z e d \n” ) ;
8 }
If the library initiation failed, the program returns an error code and the whole
program was killed since it cannot transmit or receive data without system call for Channel
Service request system call through 1609.3 libraries. Library 16093 can fail if one or more
properties are set in the WME object has already been initiated and is being used by other
applications on the device. Library 16093 was initiated for the Physical layer and so only a
library call is needed instead of low-level call. Channel access was requested upon successfully
initiation of 16093 Library.
Requesting of Channel Access was initiated in order to transmit WAVE Short Message
(WSM) on the requested channel. The following code snippet of Requesting Channel Access
implementation.
1 samplePriv−>cData . channelNo = chNum;
2 i n t r e t ;
3 // INIT CSR REQUEST
4 buildCsrReqPacket(&csrReq , samplePriv ) ;
5 r e t = wmeChannelServiceRequest(&samplePriv−>wmeCtx , &csrReq ) ;
6 i f ( r e t != WMEACCEPTED)
7 {
8 p r i n t f ( ” channel S e rv i c e r eque s t f a i l e d [ e r r o r %d ]\n” , r e t ) ;
9 e x i t (1 ) ;
10 }
11 e l s e
12 {
13 p r i n t f ( ”Channel a c c e s s reques ted \n” ) ;
14 }
27
15
16 s t a t i c void buildCsrReqPacket ( p16093WMEChannelServiceRequest ∗ req , appData
∗appDataIn )
17 {
18 req−>l o c a l I ndex = appDataIn−>wmeCtx . l o c a l I ndex ;
19 req−>ac t i on = ACTION ADD;
20 s t r cpy ( ( char ∗) req−>c h a nn e l I d e n t i f i e r . countryStr ing , ”US” ) ;
21 req−>c h a nn e l I d e n t i f i e r . ope ra t ingC la s s = 17 ;
22 req−>c h a nn e l I d e n t i f i e r . channelNumber = appDataIn−>cData . channelNo ;
23 re turn ;
24 }
Upon the success of the channel request, we construct an object for WSM. In building
WSM packets, certain criteria are needed. Followings are the properties that are needed to
be set for WSM packets: timeslot, data rate, PSID, Channel, transmission power level, and
payload length. The following code snippet of setting up WSM packets parameter.
1 wsmDataReq = (p16093WSMTxRequest ∗) mal loc ( s i z e o f (p16093WSMTxRequest ) ) ;
2 wsmDataReq−>t imeS lot = csrReq . t imeS lot ;
3 wsmDataReq−>dataRate = samplePriv−>cData . dataRate ;
4 wsmDataReq−>ps id = samplePriv−>ps id ;
5 wsmDataReq−>c h I d e n t i f i e r . channelNumber = samplePriv−>cData . channelNo ;
6 wsmDataReq−>txPwrLevel = samplePriv−>cData . txPower ;
7
8 wsmRequest . a c t i on = ACTION ADD;
9 wsmRequest . l o c a l I ndex = samplePriv−>wmeCtx . l o c a l I ndex ;
10 wsmRequest . ps id = samplePriv−>ps id ;
11 wmeWsmServiceRequest(&samplePriv−>wmeCtx , &wsmRequest ) ;
With the WSM packet constructed, the application transmits in an infinite loop (until
a SIGKILL is detected) where it will keep transmitting according to properties set in WSM
28
packet. Along with the message transmission, the application also gets GPS data on every
iteration. The GPS data are logged on the device itself with a given name for analysis
purpose. The application also calls a function which inserts/inject a custom message or data
into WSM payload and transmits the said WSM packets. The following code snippet show
transmission loop.
1 whi le (1 )
2 {
3 p r i n t f ( ”\nWaiting f o r data . . . \ n” ) ;
4 f f l u s h ( stdout ) ;
5 // try to r e c e i v e some data , t h i s i s a b lock ing c a l l
6 memset ( bu f f e r , 0 , BUFLEN) ;
7 i f ( ( r e c v l e n = recvfrom ( sockfd , bu f f e r , BUFLEN, 0 , ( s t r u c t sockaddr
∗) &remAddr , &s l en ) ) == −1)
8 {
9 e x i t (1 ) ;
10 } e l s e i f ( r e c v l e n >= BUFLEN) {
11 p r i n t f ( ”Datagram too big \n” ) ;
12 }
13 e l s e {
14 p r i n t f ( ”Bytes l ength : %i \n” , r e c v l e n ) ;
15 dataBuf fe r = mal loc ( r e c v l e n + SEQ BUFFER LEN) ;
16 memcpy( dataBuf fer , bu f f e r , r e c v l e n ) ;
17 // SEQ NUMBER BUFFER
18 s np r i n t f ( packSeq , SEQ BUFFER LEN, ”%i ” , packetsCounter ) ;
19 memcpy( dataBuf fe r + recv l en , packSeq , SEQ BUFFER LEN) ;
20 TX standard ( samplePriv , dataBuf fer , r e c v l e n + SEQ BUFFER LEN) ;
21 i f ( ! locat ionSensorGetData(&locationCTX , &lData ) )
22 pr intAna lys i sLog ( f , lData ) ;
23 e l s e
29
24 printAnalysisLogNoGPS ( f ) ;
25 f r e e ( dataBuf fe r ) ;
26 }
27 }
3.5. Variables and Implementation Constraints
3.5.1. Recorded and Calculated Variables
In order for the experiment to fit for the analysis purpose, experiments were performed
to collect specific metrics under some constraint. This was done so in order not to create
additional noise in data and get a better reading of the metrics to fit the thesis goal. Some
of the variables are recorded through the provided interface or running external application,
such as Wireshark, while some were calculated based off on the recorded variable. These
variables were used as a metric for analyzing. Table 3.2 show all the calculated and recorded
variables during all the experiments.
3.5.2. Constant Variables
For the calculated and recorded variables to have a clean reading, there are some
constraints on the experiment which apply to both applications. Table 3.3 shows all the
variables which are kept constant for both devices and applications to keep it consistent.
3.5.3. Experimental Constraints
There are some constraints applied to perform the experiments. Table 3.4 shows all
the constraints put on the experiment.
All the experiments are performed with the constraints stated above. The following
section provides the detail of the experimental setup.
3.6. Experimental Setup
All the experiments are performed with two devices that are compliant with the
above-stated standards. The devices mentioned are MINI2 and Roadstar. These devices are
30
Data Type Variable Mean Description
time t Seconds RecordedUnix Timestamp of packets
transmitted/received
subseconds t Microseconds RecordedUnix Timestamp of packets
transmitted/received
double Latitude RecordedLatitude position
(Unit: Decimal Degrees)
double Longitude RecordedLongitude position
(Unit: Decimal Degrees)
double Speed RecordedSpeed in the course direction
(Unites: meters per second)
double Relative Distance Calculated
Related distance between two devices,
calculated by the differences in latitude
and longitude locations of the devices
double Relative Speed Calculated
Related speed between two devices,
calculated by the differences in the speed
of the devices
float Jitters CalculatedPackets variance of delay in ms between
two devices
double Packet Loss CalculatedPackets loss in percentage during the
duration of transmission
double Rate of Packets CalculatedRate of packets in Mbps during the
duration of transmission
Table 3.2. Recorded and Calculated Variables
equipped with state-of-the-art hardware and standards. The devices are from Arada of Lear
Corporation.
31
Constraint Field Constraint Value Descriptions
Channel Number 178Service channel was used since
infotainment is considered a service
PSID 6PSID is set both devices for the
communication without setup
Payload Buffer Size 1375 BytesMaximum size of the WAVE
payload
IP Address 192.168.0.41IP address for the receiver to
stream out to a socket
Table 3.3. Constant Variables
Constraint Values Description
LocationStraight wide road with
almost no traffic
To avoid interference from
other vehicles through traffic
DevicesSame configuration, code,
and executable
To make sure the devices are
running the same code for
consistency
Configuration files Hard coded value
To not require the configuration
to setup every time the experiment
was ran
Log files Recorded for both devicesTo keep the metrics accurate as
possible
Table 3.4. Experiment Constraint
There are two kinds of setup performed for this paper. The first set of experiment
is a set performed to have baseline readings between two devices to have the baseline on
the device capabilities on the Basic Safety Message (BSM) application. The second set of
experiment is for video streaming purpose. The setup for these two set of experiments is
32
slightly different.
Each individual experiment in each set is performed 3 to 6 times for a specific amount
of time depending on the nature of the experiment itself. All those recorded performance
metrics are combined, compiled, and generate a dataset to calculate all the metrics needed
to compare the performance difference between BSM application and Video Streaming ap-
plication.
3.6.1. BSM Application
In the first set of experiment, MINI2 will be transmitting messages periodically from
the code running directly on the device itself while logging all the data related to the trans-
mitted messages. Roadstar is actively listening for any messages on the give Channel and
PSID and will log all data related as it received the messages on the channel. These logs will
be stored on the device itself where it will be used as a performance metric for analyzing.
This is the setup for performing all the experiments in the first set. BSM application is
tested on the route as shown in 3.5.
3.6.2. Video Streaming Application
In the second set of experiment, MINI2 will be connected to a host computer which
is capable of streaming most common video/audio codec through a VLC client. For this set
of experiment, MP4 video codec was used as it is the most common video codec. MINI2
has a port open to accept the incoming data stream as a stream of RTP packets from the
connected host. Received RTP packets are tunneled it into WSM format and transmit it out
on the service channel. For the other device, Roadstar is connected to a computer which is
capable of receiving video stream through VLC. Given that the device and the computer are
connected, Roadstar is actively listening for any messages on the given channel and PSID.
All the messages received by Roadstar will be logged and saved on the device itself. The
received packets will be decoded from WSM packets into RTP packets which will then be
funneled into a specific port that a connected computer has it opened. The computer on
the other side will receive the stream which in turn will be able to display out the videos.
33
Figure 3.5. Route taken for testing BSM Application
The setup has to be done slightly different due to the WAVE devices not having a screen
or speaker for the output as well as not having enough processing power or space to stream
natively off the device itself. Due to the nature of the setup for Set B, theoretically, it
will accommodate and support any communications between the host and the client. Video
Streaming application is tested on the route as shown in 3.6.
3.7. Summary
In this chapter, various components details such as the devices, implementation of the
code and experimental setup for each set of the experiment are described. The main aim of
the chapter is to give detail information on the implementation of TCP/IP, as described in
Section 3.3, and implementation and setup of WAVE stack, as described in Section 3.4. The
information on the recorded and calculated variable are described in Section 3.5. Section 3.6
describe the detail information about the setup that was applied when all the experiments
in each set of the experiment are performed.
34
Figure 3.6. Route taken for testing Video Streaming Application
35
CHAPTER 4
PERFORMANCE, RESULTS, AND ANALYTIC
WAVE/IEEE 802.11p was designed to prioritize periodic messaging, every 100ms
[15], to communicate with surrounding vehicles. These messages are called Basic Safety
Message (BSM) which is the main application designed for the WAVE/IEEE 802.11p. All
the data sets and details collected in this chapter for the BSM application performance on
WAVE/802.11p were performed in an open environment to imitate real-world scenario.
Several experiments were conducted to analyze for the performance between BSM
messaging application and Video Streaming application. The summary of experiments per-
formed are described in Table 4.1, where both BSM application and Video applications
were tested between 3 - 5 times for each set of experiment, depending on the nature of the
experiment, to test out the performance difference of two distinct application type using
WAVE/802.11p and WSM as a communication protocol.
All of the data set were collected by performing specific steps, from starting to com-
pletion, as stated in Section 3.6 of Chapter 3. Most of the experiment scenarios, unless
otherwise stated, are of a case where one vehicle remains stationary while another vehicle
is in motion. The stationary vehicle is a transmitter in all of the stated experiments and
the vehicle in motion is a receiver in all of the experiments. The transmitter is a more
powerful device and has better coverage, due to having more antennas, whereas the receiver
is a powerful device.
Table 4.1 shows the summary of all the experiments performed to make a comparison
between performance between BSM application and Video streaming application.
Experiments Baseline, Distance, Speed 20, and Speed 40are experiments performed
for BSM application where one device periodically transmits BSM message of 120 bytes while
the other device actively listens for BSM application on a set defined PSID and channel. The
parameters for all these experiments are according to WAVE/802.11p recommended values.
There are more details in Chapter 3.
36
Experiment Experiment Vehicle A Vehicle B
Baseline Baseline Reading Stationary Stationary
Distance Maximum Distance Stationary Moving
Speed 20 Relative Speed - 20 MPH Stationary Moving
Speed 40 Relative Speed - 40 MPH Stationary Moving
Vid 360p - Base Maximum distance for streaming Stationary Adjust Accordingly
Vid 360p - Smooth Optimal distance for streaming Stationary Adjust Accordingly
Vid 480p - Base Maximum distance for streaming Stationary Adjust Accordingly
Vid 480p - Smooth Optimal distance for streaming Stationary Adjust Accordingly
Table 4.1. List of Experiments
Experiments Vid 360pand Vid 480pare performed for the 802.11p performance for
Video Streaming for the different video resolution. Video Streaming application modified
standardized WSM parameters to accommodate video streaming. The detail configurations
for Video Streaming application experiments are expanded in Chapter 3.
Each of the experiments stated in Table 4.1 was performed between 3-5 times to
get the average reading for the performance metric comparison. Each experiment was per-
formed on a wide road with little to no traffic in order to eliminate all possible interference.
Each experiment is recorded where the results from the experiments are used for different
comparison purpose.
Delay metric referred in this chapter are referred as a time taken from the transmitter
requesting a WSM channel access to broadcast, to the other device receiving it and decoded
the WSM payload into properly format application data. Delay metrics used in this chapter
are not latency.
Bitrate metric referred in the following figures is referred to as a total number of
bits per second that was transmitted along a network that was received by the other end.
The total number of bits were only counted when the payload was able to read without any
37
errors on the receiving end. Bitrate stated in the experiments is the actual throughput of
the WAVE/802.11p network.
Packet loss metric referred in this chapter are referred to as WSM packets failed
to reach destination either with an error or was not received by the receiver at all. The
packets are also counted as a loss when they are corrupted and was not able to read by
the application. Packet loss can be caused by errors in data transmission due to network
congestion or hardware related issues.
Note that all of the experiment results are based on the experimental setup and plays
a major role in the performance metrics. The experimental setup for these experiments
are not restricted or are set up to be optimal. The experiments are set up but to be as
close as possible to the real-world scenario with actual traffic and road-conditions (turns and
elevation). This greatly affects the performance metrics [20].
4.1. Distance and Performance Metrics
4.1.1. Distance vs Delay
The first set of experiment was to analyze the relationship between distance and
delay. In the experiment, one vehicle remains stationary while the other vehicle gradually
moves away. The experiment was performed 3-5 times and all the metrics were logged on
both devices. This experiment led to a comparative performance metric between the relative
distance between two vehicles and a packet delay. Figure 4.1 shows all the average readings
during the experiments.
The average delay for both BSM application and Video Streaming application hovers
between 18.4ms and 20ms which meets the requirement for majority V2V applications [2].
For the video streaming application, depending on how the application is implemented, there
is a room for improvement for reducing the average delay.
Figure 4.1 clearly show that the packet delay is not affected by the relative distance
between two vehicles. It also shows that the maximum distance for two devices to maintain
a connection is average around 1200 feet (or) 365 meters. IEEE 802.11p radio coverage range
was, theoretically, valued at 1200 meters. The experiments show that the distance is around
38
Figure 4.1. Distance vs Delay
30.45% of theoretical value. Due to the location constraint, we were not able to perform
more than 1200 feet (or) 365 meters but as the other study shows [14], the packet delay is
not affected much by the relative distance between them.
In Figure 4.1, Video Streaming packet delay are much unstable compared to the
BSM application packet delay. Video Streaming delay hover between 18.4 ms and 19.3 ms,
depending on the Video bitrate at that given moment. The difference between the highest
delay and lowest delay is average around 1 ms. BSM application packet delay is very constant
due to the controlled transmitting rate and payload size. The average reading of between
delay and distance give a general idea of the IEEE 802.11p capability in practice.
39
4.1.2. Distance vs Bitrate
The second set of experiment was to analyze the performance that affects distance
and bitrate/throughput. One vehicle remains stationary while the other gradually move
away. The experiment was performed 3-5 times and all the metrics were logged on each
device. The findings from this experiment showed comparative performance metric between
the relative distance (of the two vehicles) and network throughput. Figure 4.2 shows all the
average readings during the experiments.
Figure 4.2. Distance vs Bitrate
The average bitrate for both BSM application and Video Streaming application is
dramatically different due to the nature of the applications, where the bitrate for Video
Streaming applications is in Mbps whereas bitrate is in Kbps for BSM application. Video
streaming application requires much higher bitrate for the video to stream smoothly whereas
40
BSM application does not need high bitrate for the periodic messaging application. For the
video streaming application, there is a room for improvement for having higher bitrate to
support higher video resolution.
In Figure 4.2, it is clearly shown that BSM application bitrate is not affected by
the relative distance where it hovers around 2 - 3 kbps. However, the bitrate for Video
streaming application started to drop below 3 Mbps around 110 feet where the packet loss,
mostly caused by errors in data transmission, started to occur around 110 feet too. More of
the packet loss is explained in Section 4.1.3.
4.1.3. Distance vs Packet Loss
The third set of experiment was to analyze the relationship between distance and
packet loss in percentage. One vehicle remains stationary while the other gradually move
away. The experiment was performed 3-5 times and all the metrics were logged on the device
itself. These experiments led to a comparative performance metric between relative distance
between two vehicles and packet loss in percentage. Figure 4.3 shows all the average readings
during the experiments.
The average packet loss for both BSM application and Video Streaming application
are similar when the relative distance between two vehicles is less than equal to 110 feet.
Once the distance gets around 100 120 feet, the Video streaming application started to receive
corrupted packets hence counting that as a packet loss. The packet loss does increases as
the relative distance between two devices goes up. Packet loss tends to be higher on the
Video Streaming application due to WSM packets being burst on the channel and causing
the video packet to not arrive in order.
Due to packet loss reaching around 20% around 100 feet for the video streaming
application, the maximum relative distance between two devices for smooth video streaming
is average around <= 110 feet for MP4 video resolution for 360P. Relative distance ¿= 100
feet causes the video to have very high jitters where the video freezes so often that it is
unwatchable. The packet loss for BSM application does not reflect so much on the distance
between two devices and BSM application is working as intended.
41
Figure 4.3. Distance vs Packet Loss in Percentage
Figure 4.3 clearly show that there are much room for improvement in Video Streaming
application for WAVE/802.11p protocol. Rather than using RTP protocols (UDP packets)
for streaming standard MP4 videos, new codecs or protocol should be implemented for the
better video streaming services to compensate for the packet loss.
4.1.4. Distance vs Performance Metrics Summary
Table 4.2 shows the summary of performance metrics compared against distance.
The delay for both BSM application and Video Streaming application is not that different
regardless of the distance between two devices. The difference for the bitrate between two
applications is caused by the nature of application where the video streaming application
would require much more higher payload size and bandwidth to meet the requirement for
42
Measurement BSMVideo Streaming
(Smooth)
Average Delay (ms) 19.56 18.64
Maximum Distance (ft) ∼1200∼110 for 360P
∼90 for 480P
Average Bitrate 2.58 Kbps 2.07 Mbps
Payload Size (bytes) 128 1375
Table 4.2. Distance Experiments Summary
the video streaming. Bitrate however does depends on the packet loss. The packet loss for
Video Streaming average around 20% around 110 feet where the most packet arriving are
corrupted where the video stream client cannot decode and hence causing it to stack up as
packet loss. Packet loss could be ease by implementing better video codecs or trying different
video streaming protocols.
4.2. Speed and Performance metrics
4.2.1. Speed vs Delay
The first set of speed experiment was to analyze the relationship between relative
speed and delay. One vehicle remains stationary while the other is in motion at a specific
speed. The experiment was performed 3-5 times and all the metrics were logged on each
device. These experiments led to a comparative performance metric between relative speed
(between two vehicles) and a packet delay. Figure 4.4 shows all the average readings during
the experiments.
The average delay for both BSM application and Video Streaming application hovers
between 16ms and 18ms which meets the requirement for majority V2V applications CITE.
The relative speed between the two devices does not affect the packet delay too much. The
experiment only measured for the constant relative speed between two vehicles and do not
count for the variance on relative speed, e.g. sudden stop in movement or vehicles stopping
43
Figure 4.4. Speed vs Delay
and moving over a length of time.
Figure 4.4 clearly show that the packet delay is not affected by the relative speed be-
tween two vehicles. This lead to the assumption that the relative speed between two vehicles
and delay has no direct effect on each other. WAVE/IEEE 802.11p radio is compensated for
the relative speed of theoretical value of 260km/h or 161.5 mph. The experiments show that
the difference in relative speed is well under the requirements. The experiments location
does not accommodate relative speed over 40 mph due to safety and security issues as well
as location constraints. The average reading between delay and relative speed give a general
idea of the WAVE/IEEE 802.11p capability in practice.
44
4.2.2. Speed vs Bitrate
The second set of relative speed experiment was to analyze for the performance that
affects between relative speed and bitrate. One vehicle remains stationary while the other
was in motion at a specific speed. The experiment was performed 3-5 times and all the
metrics were logged on each device. These experiments led to a comparative performance
metric between relative speed (between two vehicles) and bitrate. Figure 4.5 shows all the
average readings during the experiments.
Figure 4.5. Speed vs Bitrate
The average bitrate for both BSM application and Video Streaming application are
dramatically different due to the nature of the applications, where bitrate for Video Stream-
ing applications is in Mbps whereas Kbps for BSM application. Video streaming application
requires much higher bitrate for the video to stream smoothly (where it has to burst packets)
45
whereas BSM application does not need high bitrate/bandwidth for broadcasting messages
periodically. For the video streaming application, there is a room for improvement for having
higher bitrate to support higher video resolution.
Figure 4.5 clearly show that BSM application bitrate and Video Streaming application
is not affected by the relative speed where it hovers around 2 - 3 kbps for the BSM application
and 3.5 - 2.5 Mbps for the Video Streaming application. The figure also shows that the bitrate
for video application steadily as the relative speed gets higher. This is due to packet loss
occurring when the vehicles are in relatively high velocity. This lead to the assumption that
the relative speed between two vehicles and bitrate has no direct effect on each other.
4.2.3. Speed vs Packet Loss
The third set of experiment was to analyze for the relationship between relative speed
and packet loss in percentage. One vehicle remains stationary while the other was in motion
at a specific speed. Each experiment was performed 3-5 times and all the metrics were logged
on the device itself. These experiments led to a comparative performance metric between
relative speed (between two vehicles) and total packet loss in percentage against time. Figure
4.6 shows all the average readings during the experiments.
The average packet loss for both BSM application and Video Streaming application
are similar to each other. Packet loss for Video Streaming applications tends to be somewhat
higher than BSM application. The packet loss does increases gradually as the relative speed
goes up.
Due to packet loss having around 5% as the speed hover around 40 mph, it can
be predicted that the packet loss will increase as the relative speed increases. For video
streaming application, the maximum relative speed between two devices for smooth video
streaming is average around 15 - 30 mph for MP4 video resolution for 360P. Relative speed
¿= 30 mph causes the video to have very high jitters, causing the video quality to degrade.
The packet loss for BSM application does not reflect so much on the speed between two
devices.
46
Figure 4.6. Speed vs Packet Loss in Percentage
4.2.4. Speed vs Performance Metrics Summary
Table 4.3 shows the summary of performance metrics compared against speed.
Measurement BSMVideo Steaming
(Smooth)
Average Delay (ms) 17.22 17.54
Maximum Speed (mph) 40 40
Average Bitrate 1.54 Kbps 3.27Mbps
Payload Size (bytes) 128 1375
Table 4.3. Speed Experiments Summary
47
From Table 4.3, the delay for both BSM application and Video Streaming application
is not that different regardless of the relative speed between two devices. The difference for
the bitrate between two applications is caused by the nature of application where the video
streaming application would require much more higher payload size to meet the requirement
for the video streaming. Bitrate however does depends on the packet loss. The packet loss for
Video Streaming average around 5% around the highest relative speed measured (40 mph)
where the most packet arriving are corrupted where the video stream client cannot decode
and hence causing it to stack up as packet loss. Packet loss could be ease by implementing
better video codecs or trying different video streaming protocols.
4.3. Transmission Rate
The WAVE/802.11p protocol is purposely designed for BSM application where it
would broadcast a short message periodically. According to the standard defined by the
protocol, the transmission rate is set to be at every 100 ms CITE. Anything lower than
will flood the network and anything greater than that would affect the BSM performance
capabilities CITE. In order to test it out, three separate experiments, from the main testing
methodology, were tested in the lab with each devices side by side. The experiments were
tested with the condition as shown in Table 4.4. These experiments are tested for a case
whether a transmission rate for the WSM messaged would affect the packet delay rate caused
by the processing delay.
4.3.1. Transmission Rate : 1 ms
This experiment was performed with the transmission rate set to 1 ms where it would
broadcast a message size of 128 bytes every 1 ms. This meant that the WSM header will
be generated every time a message is to be broadcast. Generating burst messages would
introduce higher processing delay for generating each WSM packet header.
As shown in Figure 4.7, a processing delay is introduced when the transmission rate
is set at every 1 ms. That means it would have to generate 1000 WSM message header
per seconds. This is not as desirable as the processing power for OBUs are very limited.
48
ParameterBSM Application
Value
Video Streaming Application
Value
Channel 180 (SCH) 180 (SCH)
PSID5 for transmission,
6 for receiving
5 for transmission,
6 for receiving
Payload Size 128 bytes 1375 bytes
Transmission Rate 100 ms Burst mode
Distance Between 1 and 10 feet Between 1 and 10 feet
Speed Stationary Between 18 MPH and 45 MPH
Table 4.4. Transmission Rate: Experiment Parameters
This causes the packet delay to go up since due to the processing delay. From Figure 4.7,
one can see that the transmission rate does affect the packet delay. In Figure 4.7, both of
the graph is a sawtooth wave due to the congestion control mechanism on the MAC layer
in order to reduce the collision situations and to improve transmission performance. When
the transmission rate by the transmitter is being throttled to not flood the network hence
affecting the delay of the packet to take longer since starting time for the delay are recorded
as soon as the application requests a WSM packet to be broadcast. At every interval of the
congestion window of the 802.11p/WAVE network, there is a bit of drop in a delay where it
would send out packets as the congestion window cycle.
From Figure 4.7, The packet loss graph reflect very closely to packet delay graph
since they are dependent on each other. When a receiver does not get the expected packets,
the packet loss spikes a little bit. This is caused due to packets arriving in error and data
getting corrupted when the payload was being decoded. The packet errors could be caused
by several factors, majorly on the API itself and/or hardware related. This causes several
issues in applications that cannot tolerate much packet loss.
This experiment gives us a conclusion that WAVE/802.11p would not be good for
the bursting mode which could cause an error in packet consistently. Further research can
49
Figure 4.7. Delay for Packets at Transmission Rate (1ms)
be done on this particular topic to improve the transmission rate to accommodate all kind
of WAVE applications.
4.3.2. Transmission Rate : 20 ms
This experiment was performed with the transmission rate set to 20 ms where it
would broadcast a message size of 128 bytes every 20 ms. This meant that the WSM header
will be generated every time a message is to be broadcast. Generating burst messages would
introduce higher processing delay for generating each WSM packet header but not as much
as transmission rate at 20 ms.
50
Figure 4.8. Delay for Packets at Transmission Rate (20ms)
As shown in Figure 4.8, a processing delay is introduced when the transmission rate
is set at every 20 ms but not as high when the transmission rate is at 1 ms. This means it
is generating 50 WSM message header per seconds. This is not as bad as the transmission
rate at 1ms even though the processing power for OBU is not trying to accommodate for
it. This causes the packet delay to go up slightly which hover between 30 ms - 80 ms due
to the processing delay. From Figure 4.8, one can see that the transmission rate does affect
the packet delay slightly. Figure 4.8 portrait a square wave which is the same phenomenon
occurred in Figure 4.7, which is mainly caused by the congestion control mechanism in the
MAC layer.
51
Transmitting BSM messages at 20 ms interval, however, does not cause a packet loss
according to the experiment tested in a lab. It hovers around 1% - 3% collectively every
minute or so. There are still some packets being caused by packets arriving in error which
could be caused by several factors. This can cause some issues in applications that cannot
tolerate any packet loss but is suitable applications that can tolerate some packet loss.
4.3.3. Transmission Rate : 50 ms
This experiment was performed with the transmission rate set to 50 ms where it would
broadcast a message size of 128 bytes every 50 ms. The WSM header will be generated every
time a message is to be broadcast. Broadcasting a BSM message every 50 ms is within in
recommended acceptable transmission rate and should not affect the decay rate that much.
Figure 4.9. Delay for Packets at Transmission Rate (50ms)
52
As shown in Figure 4.9, there is little to no processing delay when the transmission
rate is set at 50 ms and it is not affecting the WSM performance at all. This means it is
generating 10 WSM message header per seconds. According to Figure 4.9, the packet delays
are performing as expected and can see that the packet delay hover around 4 ms - 10 ms,
regardless of the processing delay. From Figure 4.9, one can see that the transmission rate
at 50 ms does not affect the packet delay.
Transmitting BSM messages at 50ms interval, however, does not cause a packet loss
at all according to the experiment tested in a lab. Transmitting at 50 ms does not introduce
packet loss or packet error and is most suitable for any kind of BSM applications.
4.4. Summary
The WAVE/802.11p is specifically designed for BSM application where it would send
out small messages ( 100 bytes) periodically and it is not designed for video streaming
applications. This is due to the WAVE standard specification where it doesn’t compensate
for bursting packets but aimed more for data delivery to not have network congestion.
For all the experiments performed in this chapter, it can be seen that WSM standards
of WAVE/802.11p do not accommodate the video streaming application when using WSM
as a communication protocol. Video streaming does require bursting mode but when busting
WSM packets, the packets easily got corrupted as the relative distance between two vehicles
increases. This somewhat defeats the purpose of V2V application where it should be able to
communicate with each other in a decent range, around 200 meters, in a very short amount
of time.
The experiments also tell us that the WAVE/802.11p would be perfect for designing
and implementing BSM application in conjunction with CAN bus data. The performance
of WAVE/802.11p is rarely affected by any of the metrics that were tested against in this
chapter. However, Many improvements can be made to the V2V application as described in
Chapter 5.
53
CHAPTER 5
CONCLUSION AND FUTURE WORK
According to the real-world measurement readings for IEEE 802.11p, in combination
with WAVE stack, has a good performance and is feasible to implement in real-world for the
BSM communication. The readings from the measurements are very encouraging for BSM
application which can lead to the implementation of certain applications shown in Table 5.1.
Application Communication mode Maximum latency Range
Traffic signal violation V2I 100 ms 250 m
Curve speed warning V2I 1000 ms 200 m
Emergency brake lights V2V 100 ms 200 m
Pre-crash sensing V2V 20 ms 50 m
Forward collision V2V 100 ms 150 m
Left turn assist V2I or V2V 100 ms 300 m
Lane-change warning V2V 100 ms 150 m
Stop sign assist V2I or V2V 100 ms 300 m
Table 5.1. Feasible Applications for Implementation [14]
All of the applications shown in Table 5.1 are considered BSM applications. With the
readings from the experiment, the applications can be implemented since the readings show
that the values are close to the application requirement. As for the video streaming, as stated
by the recommended bandwidth for smooth streaming, it is recommended for the connection
to at least have 2Mb/s[2]. The higher the bandwidth, the better. Streaming quality also
depends on other factors such as video resolution, video bitrate, and video codecs.
IEEE 802.11p is not designed for streaming video naively since it would require much
processing powers for decoding and encoding videos on demand. However, all video data
stream packets can be tunneled through WAVE standards and use WSM as a communication
54
protocol. From the reading, it is possible to stream video from vehicle to vehicle at the
expense of relative distance between two vehicles for good smooth video streaming. It is not
that much feasible in the real world since V2V applications are in a high-speed environment
where the contact time between each vehicle is very short and brief.
5.1. Limitation
The current implementation on both BSM and Video Streaming application support
only specific channel and PSID. The capabilities of changing channel and PSID on the fly
was not implemented as it did not serve for the experiment purpose. Another limitation
applies to the Video Streaming application where a buffer for receiving video data stream
was limited to 1370 bytes. If a datagram size is bigger than the said buffer size, it would
cut the datagrams to fit the buffer size. This causes the datagram to sent incorrectly where
a video client read as an error and will not be decoded.
There are other limitations in a sense of how the applications are being implemented.
For the video streaming application, no code for VLC was modified to fit for our experiment
purpose. VLC was being used as it is and how a normal user would use it with default
recommended settings.
Due to the limitation of the testing ground, we were only able to perform the ex-
periments on limited testing cases. We cannot get over 45 MPH relative speed difference
when performing these experiments due to space limitation. The testing site also has some
line-of-sight problems for the experiments caused by trees.
5.2. Future Work
There are many improvements that can be made on this project as a whole. This
thesis paper is meant to serve as a performance reading on two different nature of application
as an entry point on developing V2V applications. For future work, the application can be
improved in several fields as shown in Table 5.2.
The most important to improve further on this project is to implement security on
the WSM packets that were transmitted. As far as implementation goes for this paper, it
55
Focus
FieldDescription
Security Security implementation during WSM exchange.
Network Hopping between different network and network traversal
Multi Channel Multi Channel between Control Channel and Service Channel.
Application
Extension
Applications based on CAN Bus data between vehicles
for environmental awareness.
Different
Network
Communication
Communications with other infrastructure for remote
monitoring/development, e.g. internet.
Table 5.2. Future Work Related to this Project
was sending out a raw WSM packet and hence lacking security. Security is one of the focus
area for the V2X along with network developments and structures.
By looking at the normal RTP to WSM packets for video streaming application
performance, one can see that better codec can be developed or implemented for better
performance in video streaming application.
By making use of the performance analysis of this paper, many other V2V applications
can be developed such as vehicle’s CAN bus data to be environmentally aware through other
vehicle’s CAN data. In addition to that, other types of applications can be developed to
communicate with different interfaces, e.g. traditional Wi-Fi and LTE.
On top of all of this, an implementation of network traversal for WSM packets could
be the next work. This is one of the bigger implementation of V2X due to ever-changing
topology. This is also one of the main focus areas for V2X application.
5.3. Summary
In conclusion, it is possible to have both BSM and Video Streaming application in
the real-world scenario. The experiment has shown promise to accommodate a different
56
type of applications, namely periodic messaging type of application or application that need
bursting of data to achieve some functionality. This paper serves as a reference for different
VANET application performances on WAVE supported hardware.
57
REFERENCES
[1] Global status report on road safety 2015, World Health Organization, 2015.
[2] B. Akbari, H. R. Rabiee, and M. Ghanbari, Packet loss in peer-to-peer video streaming
over the internet, Multimedia Systems 13 (2007), no. 5-6, 345–361.
[3] apoorvsaxena4, Wave system architecture, Jun 2015.
[4] Debika Bhattacharyya and Mr. Avijit Bhattacharyya, Architecture of vehicular ad hoc
network, Advances in Vehicular Ad-Hoc Networks (2010), 19–36.
[5] Safdar Hussain Bouk, Gwanghyeon Kim, Syed Hassan Ahmed, and Dongkyun Kim,
Hybrid adaptive beaconing in vehicular ad hoc networks: A survey, International Journal
of Distributed Sensor Networks 11 (2015), no. 5, 390360.
[6] Claudia Campolo, Yevgeni Koucheryavy, Antonella Molinaro, and Alexey Vinel, Char-
acterizing broadcast packet losses in ieee 802.11p/wave vehicular networks, 2011 IEEE
22nd International Symposium on Personal, Indoor and Mobile Radio Communications
(2011).
[7] Divya Chadha and Reena, Vehicular ad hoc network (vanets): A review, International
Journal of Innovative Research in Computer and Communication Engineering 3 (2015),
no. 3, 2339–2346.
[8] Lin Cheng, Benjamin Henty, Daniel Stancil, Fan Bai, and Priyantha Mudalige, Mobile
vehicle-to-vehicle narrow-band channel measurement and characterization of the 5.9 ghz
dedicated short range communication (dsrc) frequency band, IEEE Journal on Selected
Areas in Communications 25 (2007), no. 8, 1501–1516.
[9] George Dimitrakopoulos and Panagiotis Demestichas, Intelligent transportation sys-
tems, IEEE Vehicular Technology Magazine 5 (2010), no. 1, 77–84.
[10] Stephan Eichler, Performance evaluation of the ieee 802.11p wave communication stan-
dard, 2007 IEEE 66th Vehicular Technology Conference (2007).
[11] Jaroslav Frnda, Miroslav Voznak, Peppino Fazio, and Jan Rozhon, Network performance
58
qos estimation, 2015 38th International Conference on Telecommunications and Signal
Processing (TSP) (2015).
[12] Sebastian Grafling, Petri Mahonen, and Janne Riihijarvi, Performance evaluation of ieee
1609 wave and ieee 802.11p for vehicular communications, 2010 Second International
Conference on Ubiquitous and Future Networks (ICUFN) (2010).
[13] H. Hartenstein and K.p. Laberteaux, A tutorial survey on vehicular ad hoc networks,
IEEE Communications Magazine 46 (2008), no. 6, 164–171.
[14] Antonio Guerrero Ib'nez, C. Flores, P. Dami'n Reyes, Antoni Barba, and Angelica
Reyes, A performance study of the 802.11p standard for vehicular applications, 2011
Seventh International Conference on Intelligent Environments (2011).
[15] Daniel Jiang and Luca Delgrossi, Ieee 802.11p: Towards an international standard for
wireless access in vehicular environments, VTC Spring 2008 - IEEE Vehicular Technol-
ogy Conference (2008).
[16] Freddy Lecue, Simone Tallevi-Diotallevi, Jer Hayes, Robert Tucker, Veli Bicer, Marco
Sbodio, and Pierpaolo Tommasi, Smart traffic analytics in the semantic web with star-
city: Scenarios, system and lessons learned in dublin city, Web Semantics: Science,
Services and Agents on the World Wide Web 27-28 (2014), 26–33.
[17] Zeeshan Hameed Mir and Fethi Filali, Lte and ieee 802.11p for vehicular networking: a
performance evaluation, EURASIP Journal on Wireless Communications and Network-
ing 2014 (2014), no. 1.
[18] Brandon Schoettle and Michael Sivak, A survey of public opinion about connected ve-
hicles in the u.s., the u.k., and australia, 2014 International Conference on Connected
Vehicles and Expo (ICCVE) (2014).
[19] Fernando A. Teixeira, Vinicius F. E Silva, Jesse L. Leoni, Daniel F. Macedo, and
Jose M.s. Nogueira, Vehicular networks using the ieee 802.11p standard: An experi-
mental analysis, Vehicular Communications 1 (2014), no. 2, 91–96.
[20] N Vivek, S. V. Srikanth, P. Saurabh, T. P. Vamsi, and K Raju, On field performance
analysis of ieee 802.11p and wave protocol stack for v2v & v2i communication, In-
59
ternational Conference on Information Communication and Embedded Systems (ICI-
CES2014) (2014).
60