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