multi hop data transportation with wsm protocol in...
TRANSCRIPT
Multi-hop Data Transportation with WSM
Protocol in Vehicular Ad-hoc Network
by
Qing Chen
B.A.Sc, Shanghai Jiaotong University, 1989
Research Project Submitted in Partial Fulfillment of the
Requirements for the Degree of
Master of Engineering
in the
School of Engineering Science
Faculty of Applied Sciences
Qing Chen 2015
SIMON FRASER UNIVERSITY
Spring 2015
ii
Approval
Name: Qing Chen
Degree: Master of Engineering
Title: Multi-Hop Data Transportation with WSM Protocol in Vehicular Ad-hoc Network
Supervisory Committee: Chair: Andrew Rawicz Professor, School of Engineering Science
Jie Liang Senior Supervisor Associate Professor School of Engineering Science
Jiangchuan Liu Supervisor Professor School of Computing Science
Date Defended/Approved: March 24th, 2015
iii
Partial Copyright Licence
iv
Abstract
Nowadays, the wireless communication in vehicular environment is a hot topic in
automotive industry. Some communication standards and protocols have been
published to support the data transportation between vehicle and vehicle and between
vehicle and infrastructure, which is a big challenge due to the special characteristics of
vehicular ad-hoc network. In this project, we implement a hybrid stack that combines
WAVE Short Message Protocol (WSMP) with a recently developed protocol – the
Reactive, Density-aware Timely Dissemination protocol (REACT-DIS). The project will
evaluate the performance based on its throughput, goodput and packet loss ratio by
using NS3 simulation tool. Furthermore, we develop an enhanced approach that
combines the REACT-DIS protocol with the limited acknowledgement to improve the
performance of data dissemination in the system. The improvement of new approach
also minimizes the impacting range of last hopping so that only the space near the final
receiver will be impacted by the last hopping and the bandwidth of other area is not
interfered. The new approach is implemented and evaluated using NS3 network
simulator as well. Simulation results demonstrate that the enhanced approach
outperforms the REACT-DIS protocol in an environment with low or mid density but is
not ideal in high density environment.
Keywords: IEEE 802.11p, IEEE 1609, WAVE, WSMP, Vehicular Ad-hoc Network,
v
Acknowledgements
First of all, I would like to express my sincere gratitude towards my senior supervisor,
Professor Jie Liang for his patience and constant assistance during my research. His
generous guidance is essential throughout the project. I would also like to thank the
Chair, Professor Andrew Rawicz and my supervisor Professor Jiangchuan Liu for their
time and advices during my project. I also thank my co-workers at Bendix CVS for
providing various research options and useful materials especially at the beginning of
the project. Finally, I would like to thank my wife, Haiying Zhuang, my son, Ziyi Chen and
my whole family for their persistent love, support and encouragement.
vi
Table of Contents
Approval .......................................................................................................................... ii Partial Copyright Licence ............................................................................................... iii Abstract .......................................................................................................................... iv Acknowledgements ......................................................................................................... v Table of Contents ........................................................................................................... vi List of Tables ................................................................................................................. viii List of Figures................................................................................................................. ix List of Acronyms .............................................................................................................. x
Chapter 1. Introduction ............................................................................................. 1 1.1. Motivation of Research ........................................................................................... 1 1.2. Report organization ................................................................................................ 2
Chapter 2. Background ............................................................................................. 4 2.1. VANET ................................................................................................................... 4 2.2. WAVE protocol ....................................................................................................... 5
2.2.1. IEEE 802.11P ............................................................................................ 6 2.2.2. IEEE 1609 ................................................................................................. 7
2.3. Data Forwarding Mechanism .................................................................................. 7 2.3.1. Topology-based routing ............................................................................. 8 2.3.2. Geography-based routing .......................................................................... 8 2.3.3. REACT-DIS protocol ................................................................................. 9
2.4. Simulator .............................................................................................................. 10 2.4.1. NCTUns................................................................................................... 10 2.4.2. NS3 ......................................................................................................... 11
2.5. Research interest selection .................................................................................. 12 2.6. Matric ................................................................................................................... 13
Chapter 3. Implementation and Simulation ............................................................ 15 3.1. Protocol Implementation ....................................................................................... 15
3.1.1. Flooding protocol ..................................................................................... 15 3.1.1.1 Packet header ......................................................................................... 15 3.1.1.2 Design ..................................................................................................... 16 3.1.2. Reactive Density-aware and Timely Dissemination (REACT-DIS)
protocol ................................................................................................... 18 3.1.2.1 Protocol ................................................................................................... 18 3.1.2.2 Packet header ......................................................................................... 19 3.1.2.3 Design ..................................................................................................... 20
3.2. Simulation and Analysis ........................................................................................ 23 3.2.1. Topology.................................................................................................. 23 3.2.2. Parameters for REACT-DIS protocol ....................................................... 24
vii
3.2.3. Others ..................................................................................................... 25 3.3. Experiment Result ................................................................................................ 25
Chapter 4. REACT-DIS with Acknowledgement ..................................................... 30 4.1. New Approach ...................................................................................................... 30 4.2. REACT-DIS with limited ACK ............................................................................... 31
4.2.1. Fast transmission during one hop range .................................................. 32 4.2.2. Queued transmission cancellation ........................................................... 32 4.2.3. Conditional last hopping .......................................................................... 32
4.3. Implementation ..................................................................................................... 33 4.4. Analysis and Result .............................................................................................. 34
Chapter 5. Conclusion and Future Work ................................................................ 37
References ………………………………………………………………………………….39 Appendix A Source Code for REACT-DIS with LIMITED-ACK .................................. 42
viii
List of Tables
Table 1 Header Format for Flooding Protocol ............................................................... 16
Table 2 Packet header of REACT-DIS ......................................................................... 19
Table 3 Scenarios of Simulation ................................................................................... 24
Table 4 REACT-DIS Parameters .................................................................................. 24
Table 5 General configuration. ..................................................................................... 25
ix
List of Figures
Figure 1 VANET Architecture ........................................................................................ 4
Figure 2 WAVE Model vs ISO Model .............................................................................. 5
Figure 3 DSRC spectrum band and channels in the U.S. ............................................... 6
Figure 4 LLC header and SNAP header ......................................................................... 7
Figure 5 Architecture of NCTUns .................................................................................. 11
Figure 6 NS3 Conceptual Structure .............................................................................. 12
Figure 7 Packet Processing Logic for Flooding Protocol ............................................... 17
Figure 8 WSM Packet Processing Logic ....................................................................... 21
Figure 9 WSM Stack Periodical Task Logic .................................................................. 22
Figure 10 Topology of Simulation ................................................................................. 23
Figure 11 Packet Transportation Status in Space for Flooding Protocol ....................... 26
Figure 12 Packet Transportation Status in Space for REACT-DIS Protocol .................. 27
Figure 13 Throughput - Flooding vs. REACT-DIS ......................................................... 28
Figure 14 Goodput - Flooding vs. REACT-DIS ............................................................. 29
Figure 15 Packet Loss Ratio - Flooding vs. REACT-DIS .............................................. 29
Figure 16 Header Format of REACT-DIS with Limited ACK .......................................... 33
Figure 17 Throughput - REACT-DIS vs. REACT-DIS with Limited ACK ....................... 35
Figure 18 Goodput - REACT-DIS vs. REACT-DIS with Limited ACK ............................ 35
Figure 19 Packet Loss Ratio - REACT-DIS vs. REACT-DIS with Limited ACK ............. 36
x
List of Acronyms
AODV Ad-Hoc On-Demand Distance Vector Routing
BSS Basic service set
BSSID Basic service set identification
CCH Control channel
DSDV Destination – Sequenced Distance-Vector Routing
DSR Dynamic Source Routing
DSRC Dedicated short range communications
IEEE Institute of Electrical and Electronics Engineers
ITS Intelligent Transportation System
LLC Logical Link Control
MANET Mobile Ad-hoc Network
MFR Most Forward within Radius
OBU On-board unit
OLSR Optimized Link State Routing
PSID Service provider identifier
RSU Road side unit
SAE Society of Automotive Engineers
SCH Service channel
SNAP Sub-network Access Protocol
TPMS Tire Pressure Monitoring System
VANET Vehicular Ad-hoc Network
WAVE Wireless Access in Vehicular Environment
WSMP WAVE Short Message Protocol
ZRP Zone Routing Protocol
1
Chapter 1.
Introduction
1.1. Motivation of Research
The rapid developing wireless techniques are now being widely used in the
vehicle industry. The applications are not limited to satisfy local system monitoring such
as tire pressure monitoring system (TPMS) but are also developed to assist road safety,
traffic control, and transportation analysis, increase comfort of travel and support in-
vehicle entertainment.
Vehicular communication may use different types of architectures such as
cellular network architecture or ad-hoc network architecture. Cellular network has a wide
range of coverage. As far as the vehicle is in the range of a valid base station, the
cellular network is able to provide a reliable connection between vehicles or between
vehicle and service center for data transportation. The vehicles may also communicate
over ad-hoc network, calling Vehicular ad-hoc network (VANET). VANET is a special
case of mobile ad-hoc networks (MANET), in which each vehicle acts as a mobile node.
As an ad-hoc network, it does not need a base station or router to link mobile nodes
together in advance. It provides a more flexible and dynamic network which makes it
more suitable for high mobility traffic environment. [6, 11]
Because of the high mobility of the vehicles in the system, VANET has its own
special characteristics. First of all, due to various speeds and directions, the wireless
network frequently connects and disconnects. It is difficult to establish a reliable routing
path before a multi-hop communication starts. Secondly, as the traffic condition varies in
different places, the scale of the network changes. The high network scalability in
2
vehicular environment is a challenge for a routing protocol to be flexible enough to fit
different network sizes. At the same time, to protect the privacy of the user, the nodes in
the network are also secured to avoid being traced. The characteristics of VANET
makes it a big challenge to transport large amount of data, especially data streaming
such as video from point to point with multiple hops, where a stable routing path is
normally required in traditional network environment.
After many years of design and research, official standards have been gradually
published recently. IEEE introduced a series of standards called WAVE protocols
(Wireless Access in Vehicular Environment) to support vehicular ad-hoc network. The
WAVE protocol consists of IEEE 802.11p [25] and IEEE 1609 protocol [22 23 24]. It
simplifies the network establishment processes to reduce the latency and introduce a
special approach call WAVE Short Message Protocol (WSMP) that provides a
reasonable small overhead. Sponsored by Intelligent Transportation Systems (ITS),
applications in vehicle industry are developed based on the WAVE protocol and its
associated application level specification such as SAE J2735 - Dedicated Short Range
Communications (DSRC) [21] Message Set Dictionary.
In order to achieve reliable video streaming in VANET, this project will introduce,
based on WSMP, a data dissemination protocol called reactive, density-aware and
timely dissemination protocol (REACT-DIS). We will also discuss a potential
enhancement of the protocol. Simulation is used to analyze and compare the
performances of the protocols.
1.2. Report organization
In the next chapter, the report will provide some background information,
including VANET and its characteristics, WAVE protocol and its content, forwarding
mechanisms, simulation tool, and research interest as well matric used for analysis.
Chapter 3 focuses on simulation experiments to implement the enhanced
flooding protocol and REACT-DIS protocol. It is separated into two sections, the
3
implementation section and simulation section. In implementation section, we introduce
the packet header designed for each protocol and describe the logic of the major
functions using block diagrams. The simulation section describes the network topology,
the experimental scenarios and general parameter settings. Finally, simulation results of
two protocols are compared.
The entire Chapter 4 introduces a new approach that combines REACT-DIS
protocol with a limited acknowledgement. The approach is implemented in NS3
simulator. The simulation is run and its result is analysed.
The last chapter summarizes the report and provides some potential directions
for further research.
4
Chapter 2.
Background
2.1. VANET
In VANET, the communication devices can be separated into two types: on-
board unit (OBU) and road-side unit (RSU). The on-board unit is usually mounted on
vehicles and the road-side unit is usually stationary and installed alongside the road.
Figure 1 shows the general architecture of VANET.
Figure 1. VANET Architecture [8]
Due to unstable topology and frequent disconnection, video streaming becomes
a challenge in VANET. The major issue is the decrease of video quality caused by
increased delay, loss and overhead during data transportation in high dynamic
5
environment. Therefore, the traditional data routing mechanisms are no longer
completely suitable of video streaming in VANET. The new protocol stack shall have
following properties to adapt to the requirements of VANET:
Low latency
Small overhead
High scalability
2.2. WAVE protocol
WAVE protocol contains a group of protocols mcovering from physical layer up to
transport layer. The general structure of the protocol is shown in Figure 2 [13].
Figure 2 WAVE Model vs ISO Model
IEEE 1609.3
(WSMP)
TCP/UDP
IPv6
Safety
Application
(Not part of
WAVE protocol)
IEEE 802.2 (LLC sublayer)
IEEE 1609.4 (MAC sublayer extension)
IEEE 802.11P (MAC Sublayer)
IEEE 802.11P (PHY Layer) Physical Layer
Data Link Layer
Network Layer
Transport Layer
Session Layer
Non-Safety
Application
(Not part of
WAVE protocol)
Application Layer
Presentation Layer
IEE
E1
60
9.2
(S
ecurity
)
ISO Model WAVE Model
6
2.2.1. IEEE 802.11P
IEEE802.11p standard [25], finished in 2010, described the physical layer as well
as the medium access control protocols required in VANET. IEEE802.11p uses 5.9 GHz
band, from 5.85 GHz to 5.925 GHz. The 75 MHz bandwidth is divided into seven
channels as shown in Figure 3 [21]. Each channel uses 10 MHz bandwidth. Channel 178
is reserved for control information. Channel 172 and 184 are assigned for life safety and
public safety information. The rest four channels are assigned for other services.
Channel pair 174/176 and 180/182 can also individually combine into a 20 MHz channel
175 and 181 respectively.
Figure 3 DSRC spectrum band and channels in the U.S.
In order to suit for the fast changing topology of the vehicular environment, an
IEEE802.11p WAVE device is allowed to send and receive data with wildcard BSSID
without joining a BSS. The authentication process and channel scanning process that is
used by traditional 802.11 protocols are eliminated in order to reduce the time for
network establishment. As a trade, 802.11p MAC doesn’t provide data confidentiality
service. The relative service is provided by higher layer of WAVE protocol.
Theoretically, the communication distance of IEEE802.11p WAVE device is up to
1000m. The expected bitrate ranges from 3Mbps to 27 Mbps for 10 MHz bandwidth
channels.
7
2.2.2. IEEE 1609
IEEE 1609 is made up of a series of sub-specifications, mainly 1609.2 [22],
1609.3 [23] and 1609.4 [24]. IEEE1609.2 provides security function for application and
management messages. IEEE1609.3 is a specification that covers network service and
transport layer functions. IEEE1609.4 is an extension of MAC sublayer function to
support multi-channel operation.
As shown in Figure 2 , IEEE1609 supports both IPv6 TCP/UDP and WSMP.
WSMP is a special protocol designed for WAVE. It allows applications to control physical
layer characteristics such as channel used and transmission power directly. The WSMP
protocol is mainly design for safety application. But it also supports non-safety
applications.
The WSMP header contains multiple fields such as PSID, extended fields and
etc. The PSID is used to determine the application entry. The extended fields are used
for optional lower layer control parameters such as channel number, data rate and
transmit power. The header of WSMP is about 10 bytes, variable because of the length
of PSID field and optional extended fields, while the minimum head of IPv6 standard is
52 bytes. So the WSMP header is much shorter.
In order to identify between WSMP message and IPv6 message, a two-byte
ether-type field is added into SNAP header (refer to Figure 4), of which a 0x88DC
indicates a WSMP message and a 0x88DD for IPv6 message.
LLC Header SNAP Header
Protocol ID Ether-type
Figure 4 LLC header and SNAP header
2.3. Data Forwarding Mechanism
In general, ad-hoc routing protocol can be classified into topology-based
approach and geography-based approach.
8
2.3.1. Topology-based routing
The topology-based routing can be divided into three types: proactive, reactive
and hybrid. The proactive routing, for example DSDV (Destination – Sequenced
Distance-Vector Routing) and OLSR (Optimized Link State Routing), continuously
discovers the environment and keeps a table of the nearby nodes. It causes high cost of
overhead and latency for route maintenance. The reactive routing will create the route
path when necessary. An initial delay to construct the route is needed but it avoids
maintaining the routing table. AODV and DSR are the examples of reactive routing. It
partially solves the problem of proactive routing but still not efficient enough when facing
the dynamic vehicular environment. The hybrid routing protocol such as ZRP is to
combine above two approaches to improve the efficiency and scalability. The proactive
routing and reactive routing are also classified as flat routing, and hybrid routing as
Hierarchical routing.
2.3.2. Geography-based routing
Geography-based routing depends on physical position information of one-hop
neighbours and/or destination to decide the route. Since the position information is easy
to obtain due to the wide usage of GPS technology, the geography based routing is one
of the research directions in VANET.
Geography-based routing usually uses greedy strategy. For example, the Most
Forward within Radius protocol (MFR) [28] selects the forwarding node that has the most
progress (the distance between the source node and the projector of an intermediate
node on the line that connects source node and destination node) in the range of source
node. The geography-based routing may also take least distance between intermediate
node and destination node or the closest direction of intermediate node comparing the
direction of destination (called compass routing) as the strategy to determine the
forwarding nodes. Most of the strategies use destination location as a reference.
9
Geography-based routing may have sender-based forwarding or receiver-based
forwarding. In sender-based forwarding, the sender will select the relay node that will be
responsible of forwarding the message. In order to select the proper node, the sender
has to keep tracking information of its neighbours. Therefore, it is necessary for each
node to distribute its information such as position, speed, and direction, which is quite
difficult as these information keeps changes all the time in vehicular environment. The
receiver-based forwarding, on the other hand, selects the relay node by receiver. It
doesn’t have to track its neighbours nor have to understand the topology of the network
system, and hence considerably reduces the latency and bandwidth cost to construct
and maintain the route while keeps better scalability.
2.3.3. REACT-DIS protocol
The routing protocol used in the project is called Reactive, Density-aware and
Timely Dissemination introduced by Cristiano Rezende, Richard W. Pazzi and Azzedine
Boukerche [7]. As a receiver-based protocol, the sender will include its position
information in the packet. The forwarding node will calculate the distance between the
sender and itself, and then use greedy strategy to decide if it shall relay the packet or
not. The further the forwarding node is, the higher the priority to reply the packets. To
fulfill this algorithm, a forwarding node won’t relay the packet immediately when it
receives a packet. Instead, when a packet is received the first time, the forwarding node
will assign a short delay for the received packet depending on the distance with the
sender and relay the packet after the delay time expires. In order to prevent the problem
of connection disruption in low density traffic area and broadcast storming in high density
traffic area, the protocol include a density awareness mechanism. The forwarding node
will increment a counter every time the same packet is received during the delay. When
the delay expires, it will calculate a forwarding probability based on the number of the
same packet received during the delay and decide the relay operation accordingly. It
also includes other algorithms to solve the problem such as long end-to-end propagation
delay due to the wait time of each forwarding node, especially when multiple hopping is
required between the data source and final user. The protocol has following
characteristics:
10
Delivery guaranteed by redundant retransmission during datadissemination.
Storming issue prevented by involving a set of algorithms that will beintroduced in details in Chapter 3
Overhead limited by working with WAVE protocol
Propagation delay limited by including a relay mode in which the receivedpacket will be forwarded with short delay
Scalability enhanced by including density awareness algorithm
2.4. Simulator
Due to the high research cost in real VANET environment, network simulators
are widely used to design and analyze the performance of various protocols, for example
NS2, NS3, OMNet, and NCTUns. In this research, NCTUns and NS3 are two options
selected at the beginning of the research preparation because both of them have WAVE
protocols implemented.
2.4.1. NCTUns
NCTUns is a simulation tool that was developed by Prof. S.Y. Wang in National
Chiao Tung University. It can work both as a network simulator or an emulator. NCTUns
provides GUI for user to easily create network topology, add, remove or change the
protocols at different layer to create user’s own communication stack, run and replay the
simulation in graphical interface. Figure 5 shows the architecture of the tool. The
distributed architecture of the tool also enables remote simulation and simultaneous
simulation. [15, 16, 17, 27]
11
Figure 5 Architecture of NCTUns
The integrated traffic simulation function of NCTUns tool allows user to define the
road map, the vehicle nodes and the traffics in GUI interface, and modify communication
stack for each of the nodes and mobility parameters, which makes it a handy tool for
VANET simulation.
NCTUns was open-source and available for free up to version 6.0. NCTUns was
commercialized since 2012 and renamed as EstiNet. The source code and the technical
support are now available depending on the license purchased.
2.4.2. NS3
NS3 tool is a new discrete-event simulator that is to replace NS2 [18]. A discrete-
event simulator means that “a point in simulation time is assigned to every event, events
are initiated and triggered consecutively and simulation time moves in discrete jumps
from event to event” [9].
NS3 is aimed for research and education. NS3 is developed in C++ and
incompatible of NS2. NS3 has five general elements: node, application, net device, stack
12
and channel. To make the simulator easy to use, helper class is developed in most of
the modules to assist creating and configuring simulator application.
Figure 6 NS3 Conceptual Structure
NS3 is open-source and is well-documented. A WAVE module is developed,
which includes IEEE 802.11p and WSM protocol. But, there is no traffic simulator
developed in NS3. Instead, NS3 uses mobility module to add and configure mobile
parameters for the nodes.
2.5. Research interest selection
In order to achieve data streaming in VANET, the first thing is to design an
appropriate stack that is suitable for high dynamic VANET environment. This project
focuses on integrating a stack and analyzing the performance using the simulator. In the
stack, IEEE 802.11p is selected to form the PHY and MAC layer. Network layer uses
WSMP protocol of IEEE-1609 protocol to provide low latency and small overhead.
Above them, REACT-DIS protocol is implemented to provide forwarding algorithm that
satisfy the dynamic VANET environment. At the end of the research project, a new
improved REACT-DIS protocol called REACT-DIS with limited ACK is designed and
implemented, and its performance is analyzed as well.
Node
Application
Stack
Net Device
Channel Network
13
When selecting network simulator, NCTuns was first investigated but NS3 tool is
finally selected because, based on the research interest of this project, mobility module
of free open-source NS3 tool provides sufficient needs in the simulation.
2.6. Matric
To compare the performance, an enhanced flooding protocol is implemented and
is used as starting point. Then, the reactive, density-awareness and timely dissemination
protocol is implemented and the performance is compared in throughput, goodput and
packet loss ratio.
In communication network, throughput is usually used to measure the
performance. Throughput of a communication network is “the rate of successful message
delivery over a communication channel” [6]. In the research, the throughput is calculated
based on data received by the receiver in follow method:
𝑇ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 =𝑡𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑏𝑖𝑡𝑠 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑
𝑡𝑖𝑚𝑒
However, since the packets are transported in broadcast manner and redundant
transmission is used to increase the reliability of data transportation, there are a lot of
retransmissions and overhead during communication in simulation. From application
point of view at receiver side, the redundant data are useless. As a comparison, the
goodput is calculated to measure the number of useful data transmitted to receiver.
𝐺𝑜𝑜𝑑𝑝𝑢𝑡 =𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑢𝑠𝑒𝑓𝑢𝑙 𝑏𝑖𝑡𝑠 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑
𝑡𝑖𝑚𝑒
Packet loss is also used to measure the reliability of the protocol for data
transportation. Due to the nature of broadcast during multiple hopping, the collision will
happen even though only one service is running in the simulation. Although redundant
transmission will help to avoid packet loss, the packet loss may happen still during
14
transmission. In this project, the packet loss ratio is used to measure the packet loss
status in the network.
𝑃𝑎𝑐𝑘𝑒𝑡 𝑙𝑜𝑠𝑠 𝑟𝑎𝑡𝑖𝑜 =𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑚𝑖𝑠𝑠𝑒𝑑
𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑢𝑠𝑒𝑓𝑢𝑙 𝑝𝑎𝑐𝑘𝑒𝑡 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑
15
Chapter 3.
Implementation and Simulation
During the research, groups of simulation experiments are run using NS3
simulator to simulate different protocols and the new approach, and validate the
performance of various designs in VANET. In this chapter, we will introduce the
implementation of the enhanced flooding protocol and REACT-DIS protocol, and their
simulation details.
3.1. Protocol Implementation
3.1.1. Flooding protocol
Flooding protocol is a traditional routing protocol that doesn’t need route
discovery and maintenance. It uses broadcast to flood the network by continuously
sending each packet it receives to its neighbours. Because of redundant packet
broadcast and all route paths are used, the delivery quality and the shortest path is
guaranteed.
3.1.1.1 Packet header
In the process of flooding protocol, two restrictions are included to avoid
duplicated packets sent from one node and prevent broadcast storming in the network:
Tracking each packet received and its timestamp to guarantee that the samepacket is delivered only once.
Setting maximum hop for each packet so that the broadcast stops if themaximum hop reaches
16
In the experiment, a header is designed to contain essential information for the
intermediate node to make a forwarding decision. The header has the format as shown
in Table 1.
Sender Seq No. Hop
Name Length Description
Sender 4 bytes The ID of initial data source
Seq 1 byte Sequence no of the packet sent by the data source
Hop 1 byte Maximum hops that next node shall carry on
Table 1 Header Format for Flooding Protocol
3.1.1.2 Design
The following diagram shows the processing logic of flooding protocol when a
packet is received.
17
Figure 7 Packet Processing Logic for Flooding Protocol
Is the a receiver?
Retrieve packet header
Is the packet received before?
Record message
Is max. hops zero?
Get max. hops from header
Max. hops - 1
Build header with Max. hops
Send packet with new header
Yes
No
No
Yes
No
Yes
Transmit message to
application to process
(Ignored in simulation)
18
3.1.2. Reactive Density-aware and Timely Dissemination (REACT-DIS) protocol
3.1.2.1 Protocol
As introduced in section 2.3.3, the REACT-DIS protocol contains three main
algorithms to control the dissemination operation. They are forwarding delay selection,
density awareness and maximum relay. [7 10]
1. Forwarding delay selection
Each node that receives a message will choose a delay time based on the
distance between the sending node and itself. The delay time is inversely proportional to
the distance. Therefore, the node that is further away from the sender will have higher
priority to relay the message.
𝑡 = [(1 −𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
𝑅) (𝑇𝑚𝑎𝑥 − 𝑇𝑚𝑖𝑛)] + 𝑇𝑚𝑖𝑛
2. Density awareness
In order to avoid the high packet collision situation in high node density
environment, the protocol includes a forwarding probability. Each node will count how
many times the same packet is received during the delay time and calculate the
forwarding probability based on the count. With the increase of duplication of one
packet, the probability of retransmission will reduce. The relationship is shown as follow:
𝜌 =1
𝑟𝑐𝑜𝑢𝑛𝑡−1
where r is forwarding probability reducer. Based on test, the ideal value of r is 10.
[7].
3. Maximized relay
19
An issue of reactive approach is the end-to-end delay accumulated from the
waiting time described in the first algorithm during multiple hops. To avoid this issue,
once a node decides to relay a packet, it will retain in relay mode for a certain time ∅. As
a result, the node in relay mode won’t compete for forwarding based on distance in this
∅ time period. It will just wait for a very short delay before it forwards new received
packet. However, there could be a chance that at one certain time period, there are
excessive numbers of nodes are in relay mode. This will again cause more than enough
redundant packet transmissions and raise the possibility of collision. To solve the
problem, another probability is included in the protocol as follow:
𝛿 = {1 𝑐 ≤ 𝑘1 − (𝑐 − 𝑘) ∗ 𝜏 𝑐 > 𝑘
where c is the number of the redundant packets transmitted, k is the expected
number of forwarding and 𝜏 is the forward reducing factor. Based on the evaluation, the
ideal k is 4 [7].
3.1.2.2 Packet header
Based on the protocol, the forwarding nodes that receive the packets need the
position information of the previous hop node. Therefore, the packet header is extended
to include two fields for X position and Y position, as shown below
Sender Seq No. Hop X Position Y Position
Name Length Description
Sender 4 bytes The ID of initial data source
Seq 2 bytes Sequence no of the packet sent by the data source
Hop 1 byte Maximum hops that next node shall carry on
X position 8 bytes X position of the transmitter when a packet is sent
Y position 8 bytes Y position of the transmitter when a packet is sent
Table 2 Packet header of REACT-DIS
20
3.1.2.3 Design
In the experiment, REACT-DIS protocol is implemented in a MyWSMStack class.
The major functions of this class include 1) processing received packets; 2) maintaining
queued packets and packets history; and 3) transmitting the packet when the forwarding
condition matches. When a WSM packet is received, the WSM packet processing
function is triggered. It disassembles the packet header and, based on the logic shown
in Figure 8, assigns either SCHEDULE_MODE or RELAY_MODE or NORELAY_MODE
for each packet. A periodical handler then scans through queued packets to decide if a
packet in SCHEDULE_MODE or RELAY_MODE shall be sent or not when time is due.
When a queued packet is sent, the packet is assigned with RELAYED_MODE.
Otherwise, NORELAY_MODE is assigned. The handler also checks if the relay mode of
the forwarding node is time-out or not. Figure 9 shows the control logic of the periodical
task based on REACT-DIS protocol. In order to track the received packets, the stack
contains a member called m_MsgHistory. A set of methods are also implemented to
maintain this message queue and remove the message when it expires. A
WSMProtocolHeader class is implemented to handle the packet header as mentioned in
section 3.1.2.2.
To simply the configuration in simulation application, MyWSMStackHelper is
implemented to help installing the MYWSMStack to one node or a group of nodes
(called NodeContainer in NS3 tool).
The following diagrams show the packet processing logic and the periodical task
control logic implemented for REACT-DIS protocol
21
Figure 8 WSM Packet Processing Logic
Is the node a receiver?
Retrieve packet header
Is the packet received before?
Record message
Is max. hops zero?
Get max. hops from header
Max. hops - 1
Set NORELAY_MODE
Yes
No
No
Yes
No
Yes
Increment count of message
Is in Relay mode?
Set a random delay based on distance
Calculate distance
Set random delay
Set SCHEDULE_MODE
Set RELAYING_MODE
No
Yes
Transmit message to application to process (Ignored
here)
22
Figure 9 WSM Stack Periodical Task Logic
RELAYING MODE
Reset NodeRelayMode if NodeRelayMode times out
SCHEDULE MODE
rece
For each queued message
Others
Evaluate Mode
IF delay time expires { IF (condition 2 of section 3.1.2.1) Send packet Set to RELAYED_MODE
Set NodeRelayMode flag Set NodeRelayMode timer
ELSE Set to NORELAY_MODE }
IF delay time expires { IF (condition 3 of section 3.1.2.1) Send packet Set to RELAYED_MODE ELSE Set to NORELAY_MODE }
23
3.2. Simulation and Analysis
3.2.1. Topology
In this research, we assume that all nodes know their positions in a 750mx750m
2D space. There is no obstacle between nodes to block the wireless communication. All
nodes have the same transmission range. To simply the experiment, we assign a node
as a packet generator and another node as a receiving node. Both nodes start from the
center of the map and move in opposite direction at a constant velocity. At the same
time, there are hundreds of fixed nodes evenly distributed in the 2D space and act as
forwarding nodes. Figure 10 shows the general topology of the simulation.
Figure 10 Topology of Simulation
There are three main scenarios designed based on number of forwarding nodes
at the background, 256 nodes, 961 nodes and 2601 nodes (refer to Table 3). From
0 1 20
R
G
n
d
v
v
24
scenario 1 to scenario 3, each of them individually represents the low density
environment, the mid density environment and the high density environment.
Scenario Nodes per row Number of rows Distance in meters (d) Number of nodes
1 16 16 50 256
2 31 31 25 961
3 51 51 15 2601
Table 3 Scenarios of Simulation
The velocities of the packet receiver and the packet generator are both 35.35 m/s
in all simulations. The packet receiving node goes towards node 0 and the packet
generating node towards node n in the simulation.
3.2.2. Parameters for REACT-DIS protocol
In REACT-DIS protocol, the values used for parameters of three algorithms
mentioned in section 3.1.2.1 are shown in Table 4
Symbol Description Value Algorithm
R Redius 180 m 𝑡 = [(1 −
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒
𝑅) (𝑇𝑚𝑎𝑥
− 𝑇𝑚𝑖𝑛)] + 𝑇𝑚𝑖𝑛
Tmax Maximum delay time 100 ms
Tmin Minimum delay time 10 ms
r forwarding probability reducer 10 𝜌 =
1
𝑟𝑐𝑜𝑢𝑛𝑡−1
k Expected number of forwarding 4 𝛿 = {
1 𝑐 ≤ 𝑘1 − (𝑐 − 𝑘) ∗ 𝜏 𝑐 > 𝑘
τ forward reducing factor 0.1
Table 4 REACT-DIS Parameters
Besides above parameters, the maximum time for a node to stay in relay mode
(time ∅) is 100ms.
25
3.2.3. Others
Although our experiment is developed based on WSMP, WSMP is not the major
focus of this research. The research is concentrated on the performance of the
forwarding protocol with continuous data transportation under scenarios mentioned in
section 3.2.1. As WSMP control message is not part of this research, the simulation
experiment is simplified by excluding the 100-ms control message on CCH and all
WAVE management messages required by WSMP protocol. Except specifically defined
in the simulation application, the default configurations of WAVE module are used in the
simulation.
The data transportation will start one second after the beginning of the simulation
to create an initial distance between packet generator and packet receiver but still keep
them in one hop range. The entire simulation will run for fifteen seconds. Table 5 shows
the general configuration used in the simulation.
Sending period (ms) 100
Maximum transmission range of WIFI 250 m
Maximum allowed hops 4
History packet timeout (ms) 2000
Packet size (bytes) 1000
Table 5 General configuration.
To trace the simulation, a packet capture function in NS3 simulator is enabled at
physical layer to capture all transmitted packets or received packets and save them
into .pcap file in the simulation. WireShark network protocol analyzer is used for data
analysis after the simulation.
3.3. Experiment Result
Comparing the results of the simulations with 963-node scenario, the packet
transportation status of flooding protocol is much worse than that of REACT-DIS
protocol. Although theoretically the network with flooding protocol shall transport more
26
packets, the peak number of the packets transported is only 498 packets with flooding
protocol, while 794 packets are transported in the network with REACT-DIS. This
indicates that a severe packet collision and data loss situation happens in the network
with flooding protocol. At the same time, from Figure 11 and Figure 12, it is obvious that
the real network covering range of REACT-DIS protocol is much further than that of
flooding protocol even though both of them have four hops and the configurations at the
physical layer are the same.
Figure 11 Packet Transportation Status in Space for Flooding Protocol
0
175
350525
700
0
100
200
300
400
500
05
01
00
15
02
00
25
03
00
35
04
00
45
0
50
0
55
0
60
0
65
0
70
0
75
0
Y (m)
Nu
mb
er
of
Pac
kets
X (m)
27
Figure 12 Packet Transportation Status in Space for REACT-DIS Protocol
From the throughput point of view, the data rates of the receiver in all three
simulations remain low at about 135Kbit/s with flooding protocol, which are resulted from
poor network performance such as high network congestion, packet collision and small
network cover range. Comparatively, the throughput with REACT-DIS protocol is much
better. With the increase of the density, the throughput also increases because more
retransmissions occur due to more nodes in the area. In other words, the REACT-DIS
protocol is much more flexible and has much better scalability in a dynamic vehicular
environment.
0
175
350
525700
0
200
400
600
800
05
01
00
15
02
00
25
03
00
35
0
40
0
45
0
50
0
55
0
60
0
65
0
70
0
75
0
Y (m)
Nu
mb
er
of
Pac
kets
X (m)
28
Figure 13 Throughput - Flooding vs. REACT-DIS
Neglecting retransmission and overhead, the goodputs are quite even in three
scenarios either in the simulation with flooding protocol or in the simulation with REACT-
DIS protocol. It is 74Kbit/s in the network with REACT-DIS protocol, comparing a
51Kbit/s goodput in flooding protocol network. From packet loss ratio diagram, the ratio
of REACT-DIS protocol network is 7.3%, comparing that of 36.6% for enhanced flooding
protocol. Therefore, the overall performance of REACT-DIS protocol is much better than
that of enhanced flooding protocol.
0
0.1
0.2
0.3
0.4
0.5
0.6
258 963 2603
Thro
ugh
pu
t M
bit
/s
Number of Nodes in 750mx750m area
Flooding
REACT-DIS
29
Figure 14 Goodput - Flooding vs. REACT-DIS
Figure 15 Packet Loss Ratio - Flooding vs. REACT-DIS
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
258 963 2603
Go
od
pu
t M
bit
/s
Number of Nodes in 750mx750m area
Flooding
REACT-DIS
0
5
10
15
20
25
30
35
40
258 963 2603
Pac
ket
loss
rat
io (
%)
Number of Nodes in 750mx750m area
Flooding
REACT-DIS
30
Chapter 4.
REACT-DIS with Acknowledgement
4.1. New Approach
Based on REACT-DIS protocol, each packet will be transported in all directions
for the maximum allowable hops. From Figure 12, though the network using REACT-DIS
protocol covers wider range and may reach further to the receiver node, it also means
that each transmission will impact more nodes in the simulation space. No matter how
close the data source and the receiver are, any transmission will cause a waste of
bandwidth in outer range of entire hopping area, resulting redundant retransmission and
causing packet collision. The larger the number of the allowed hops, the wider the
impacted range is and the worse the potential packet collision is. At the same time, due
to lack of the receiving status of each packet, the data source has to broadcast the
packet at a default rate even though the previous packets are already received. At the
same time, since there is no way for the data source to detect whether the receiving
node exceeds its maximum hopping range, it will keep broadcasting the data until the
data is completely transmitted.
To avoid these issues, the data transportation shall involve a backward
acknowledgement to inform either the sender or the forwarder the receiving status.
There are two types of acknowledgement mechanisms that could be integrated here:
complete acknowledgement and limited acknowledgement. For complete
acknowledgement, the system will try to transmit the ACK packet from the receiver all
the way back to the data source within the network. The advantage of the mechanism is
that the data source is able to detect the receiving status and then transfer new packet
as quickly as possible and terminate a transmission service in case the
31
acknowledgement packet is no longer received. Theoretically, since both the receiving
node and the forwarding nodes know the position where the packet is sent from, the
ACK packet is able to be transferred backward. However, this also means that, more
packet transportations will happen within the hopping range and will result in high
probability of packet collision. The sender may also terminate the service mistakenly
because of the loss of the acknowledgement packet during forwarding. Therefore, the
entire control algorithm of the complete backward acknowledge will be very complex.
Due to the time limitation, a limited acknowledgement is selected to be integrated
with REACT-DIS in this research, which we call it REACT-DIS with limited ACK, to
improve the performance of the data transportation. In REACT-DIS with limited ACK
protocol, only the receiver node will broadcast an acknowledgement packet to its
neighbour nodes after it receives a packet. The forwarding nodes that receive the ACK
packet won’t relay the ACK packet any further. With limited acknowledgement, the
sender is able to immediately launch new packet transmission if it receives the
acknowledgement from the receiver. This mechanism will accelerate the data
transportation when the receiver is within one hop range of the data source. At the same
time, instead of transporting the packet with maximum allowed hops, the last hopping
will be conditional so that, the forwarding nodes cancel last hopping in case it doesn’t
receive the acknowledgement from the receiver before. In this way, the overall
transmission range of a service is reduced and the bandwidth at the most outside hop is
saved. However, the REACT-DIS with limited ACK won’t guarantee receiving of
acknowledgement. The sender will continue data transmission until all the data are sent
if the ACK packet is lost or the receiver is out of one hop range of the sender.
4.2. REACT-DIS with limited ACK
Besides the major forwarding node selection criteria of REACT-DIS, the REACT-
DIS with limited ACK protocol has three differences comparing REACT-DIS protocol
after involving the acknowledgement packet:
1) one-hop fast transmission,
32
2) queued transmission cancellation, and
3) conditional last hopping.
4.2.1. Fast transmission during one hop range
When the receiver is close enough to the sender, the sender is able to receive
the acknowledgement of the previous transmission and launch a new transmission
immediately instead of waiting for a fixed interval. This will accelerate the data
transportation whenever possible. The fast transmission will be terminated automatically
when the sender no longer receives the ACK packet from the receiver.
4.2.2. Queued transmission cancellation
Based on the acknowledgement packet, the nodes nearby are able to realize the
receiving status of the receiver. It will cancel that queued transmissions if those packets
are already received and acknowledged by the receiver. This will save the bandwidth
and again reduce the probability of collision.
4.2.3. Conditional last hopping
Obviously the last hop will cover much broader area than that of the inner hop.
The proposed approach attempts to cut down multiple hopping dissemination range by
one hop. The nodes will cease the last hop if they don’t receive the acknowledgement
packet from receiver for last several packets. Otherwise, they will complete the last hop
by sending the new packet if they receive the ACK of previous packets.
Due to the possibility of the packet loss, the receiver node is allowed to transmit
multiple acknowledge packets for a same data packet in the approach to increase the
reliability of transmitting the acknowledgement information.
33
4.3. Implementation
To identify between regular data packet and the acknowledgement packet, one
byte is included in packet header, called packet type. A value of 0 means data type
packet and a 1 refers to ACK type. Figure 16 shows the header that is used for REACT-
DIS with limited ACK.
Sender Seq No. Hop X Position Y Position Packet-Type
Figure 16 Header Format of REACT-DIS with Limited ACK
The sender will generate new packet in following method:
IF (receiving ACK of previous packet)
Transmit new packet
ELSE
Transmit new packet when time due
Set next transmission time
At the same time, for the final receiver, it will operate as follow:
IF (new data packet received)
Transmit ACK packet
ELSE IF (retransmission of latest data packet received &&
ACK count is less than 3)
Transmit ACK
The forwarding node will have to record both data packets and their ACK
statuses in the simulation. In case the ACK packet is received before a data packet,
which is possible because of multi-hop operation, the forwarding node shall also record
the ACK packet. When a new packet is received, besides using processing logic as
shown in Figure 8 to determine the mode for the packets that have two or more hops
left, the following control mechanism is applied for the packets with one hop left:
IF (a packet is received with only one hop left && the ACK of any of last
two packets is received)
34
Apply packet processing logic of REACT-DIS (Figure 8)
ELSE
Set packet to NORELAY_MODE
Right before relaying a queued packet, the forwarding node will check the ACK
status of the relative packet and will stop the transmission if the acknowledgement
associated with this packet is received, as required in section 4.2.2.
The Appendix A lists the code implemented for REACT-DIS with limited ACK.
4.4. Analysis and Result
Similar as before, three simulations are run individually with 258 nodes, 963
nodes and 2603 nodes. Comparing with REACT-DIS protocol, the throughput of new
approach is better when the node density is low but is worse when node density
increases. The goodput performance is greatly improved when there are 258 nodes in
the simulation range. With 14% increase of throughput, the goodput reaches 146Kbit/s,
double the goodput of REACT-DIS protocol. The packet loss ratio decreases to 3.42%
which is 11.5% with REACT-DIS protocol. In the simulation with 963 nodes, the goodput
is 98.6Kbit/s, which is not as good as that with 258 nodes. But it is still 29% higher than
that of REACT-DIS protocol. The packet loss ratio reduces to 1.22%, which is 4.48%
with REACT-DIS protocol. With smaller hopping range, the performances of new
approach with 258 nodes and 963 nodes are better than that of REACT-DIS protocol.
35
Figure 17 Throughput - REACT-DIS vs. REACT-DIS with Limited ACK
Figure 18 Goodput - REACT-DIS vs. REACT-DIS with Limited ACK
0
0.1
0.2
0.3
0.4
0.5
0.6
258 963 2603
Thro
ugh
pu
t M
bit
/s
Number of Nodes in 750mx750m area
REACT-DIS
REACT-DIS-ACK
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
258 963 2603
Go
od
pu
t M
bit
/s
Number of Nodes in 750mx750m area
REACT-DIS
REACT-DIS-ACK
36
Figure 19 Packet Loss Ratio - REACT-DIS vs. REACT-DIS with Limited ACK
However, when the density is high, the performance of REACT-DIS with limited
ACK is not ideal. Although the goodput looks a bit better than REACT-DIS, but the actual
connection time between sender and receiver drops down to 4.47 seconds, while it is
6.71 seconds in REACT-DIS. In other words, the valid communication time decreases,
which causes the drop of total data transported during simulation. At the same time, the
packet loss ratio increases significantly from 5.97% (with REACT-DIS protocol) to
21.7%. This is because, even though the REACT-DIS protocol has density-awareness
functionality, the packet retransmission increases still when the number of nodes in the
range increases. This situation becomes dramatically worse due to fast transportation
algorithm and causes critical collision issue and blocks the packet transportation in the
network. Even after the fast transportation stops, this situation last within the network for
a period of time because of multiple hopping. Therefore, stricter retransmission limitation
criteria shall be designed in order to make REACT-DIS with limited ACK protocol work in
high density environment.
0
5
10
15
20
25
258 963 2603
Pac
ket
loss
rat
io (
%)
Number of Nodes in 750mx750m area
REACT-DIS
REACT-DIS-ACK
37
Chapter 5.
Conclusion and Future Work
This project implemented the recently developed REACT-DIS protocol for multi-
hop data transportation in VANET environment. A number of simulations are designed
and run in NS3 to compare the performance of REACT-DIS protocol with that of the
improved flooding protocol. The simulation result shows that the REACT-DIS protocol is
able to forward data by intelligently selecting the forwarding nodes in a high dynamic
environment without creating a route path in advance. Its density awareness algorithm
helps to control the duplicated transmissions in different environment with various node
densities. However, the fixed transmission rate of REACT-DIS limits the speed of the
data transportation. Since the lack of the packet receiving status, the forwarding node
will continue to relay the data to its neighbours until the maximum allowed hops reaches.
Without extra information, the sender will not terminate the data transportation until all
data are transmitted.
To partially solve the problem, this project proposes a new design which includes
a limited acknowledgement into REACT-DIS protocol, called REACT-DIS with limited
ACK. With this new approach, the sender in one hop range or the intermediate nodes
near the receiver are able to realize the receiving status and thus decide its packet
generation rate or relay behavior as describe in section 4.2.1, 4.2.2 and 4.2.3. The
protocol is implemented and the simulations are run again in NS3 simulator. The result
shows that when in the low or mid density environment, the new approach out-performs
the REACT-DIS protocol. But it is not suitable for high density environment without a
strict retransmission criterion.
38
As part of the research for video streaming over VANET, there are still some
open topics that worth further research. The following list provides several potential
research directions that can be considered after this project
Include application layer for video streaming. As a further analysis, a propervideo streaming protocol shall be designed at application layer to meet thespecial requirements of VANET environment.
REACT-DIS with complete ACK. Due to time limitation, only limited ACK isdesigned and observed in simulation. It will be interesting to have anapproach with complete backward acknowledgement implemented andanalyzed.
Multiple services in the same network. This research only observes theperformance of the protocol where only one service is running in theenvironment. The fairness of the protocol is not studied and may worthobserving in future.
39
References
[1] Ming-Chin Chuang and Meng Chang Chen. DEEP: Density-Aware Emergency Message Extension Protocol for VANETs, IEEE Transactions on Wireless Communications, Vol. 12, No. 10. October 2013
[2] M.Chitra and S. Siva Sathya, Efficient Broadcasting Mechanisms for Data Dissemination in Vehicular Ad Hoc Networks, International Journal of Mobile Network Communications & Telematics (IJMNCT) Vol. 3, No.3, June 2013
[3] Francisco J. Ros and Pedro M. Ruiz and Ivan Stojmenovic, Reliable and Efficient Broadcasting in Vehicular Ad Hoc Networks, Vehicular Technology Conference, 2009. VTC Spring 2009, IEEE 69th, Pages 1-5, April, 2009
[4] Maziar Nekovee and Benedikt BjarniBogason, Reliable and Efficient Information Dissemination Intermittently Connected Vehicular Ad Hoc Networks, Vehicular Technology Conference, 2007. VTC2007-Spring IEEE 65th, Pages 2486-2490, 2007
[5] Dharmendra Sutariya and Dr. S. N Pradhan, Data Dissemination Techniques in Vehicular Ad Hoc Network. International Journal of Computer Applications (0975-8887) Volume 8— No. 10, October 2010
[6] en.wikipedia.org/wiki/
[7] Cristiano Rezende, Richard W. Pazzi, Azzedine Boukerche, A Reactive Solution with a Redundancy-based Error Correction Mechanism for Video Dissemination over Vehicular Ad Hoc Networks. The 15th ACM internation conference on Modelling, analysis and simulation of wireless and mobile systems, Pages 343-352, 2012
[8] A. Festag, G. Noecker, M. Strassberger, A. Lübke, B. Bochow, M. Torrent-Moreno,
S. Schnaufer, R. Eigner, C. Catrinescu, and J. Kunisch, ’NoW – Network on
Wheels’: Project Objectives, Technology and Achievements. 5th International Workshop on Intelligent Transportation (WIT), pages 211-216, Hamburg, Germany, March 2008
[9] Sebastian Rampfl, Betreuer: Florian Wohlfart, Daniel Raumer, Network Simulation and its Limitations, Seminars FI / IITM / ACN SS2013, Network Architectures and Services, August 2013
40
[10] Naeimipoor, F., Boukerche, A. A Hybrid Video Dissemination Protocol for VANETs. Communications (ICC), 2014 IEEE International Conference on, DOI 10.1109/ICC.2014.6883304. Page 112-117, June 2014
[11] Prabhakar Ranjan, Kamal Kant Ahirwar, Comparative Study of VANET and MANET Routing Protocols. Proc. Of the International Conference on Advanced Computing and Communication Technologies (ACCT 2011)
[12] N. Qadri, M. Altaf, M. Fleury, and M. Ghanbari, Robust Video Streaming over an Urban VANET. Wireless and Mobile computing, Networking and Communications, 2009. IEEE International Conference, Oct. 2009
[13] Intelligent Transportation Systems Using IEEE 802.11p Application Note, online available http://www.academia.edu/10426361/Intelligent_Transportation_Systems_Using_IEEE_802.11p_Application_Note_Table_of_Contents
[14] Sujata v. Mallapur, Siddarama R. Patil, Survey on Simulation Tools for Mobile Ad-Hoc Networks. IRACST-International Journal of Computer Networks and Wireless Communications (IJCNWC), ISSN: 2250-3501 Vol.2, No.2, April 2012
[15] Shie-Yuan Wang, Chih-Che Lin, NCTUns 5.0: A Network Simulator for IEEE 802.11(p) and 1609 Wireless Vehicular Network Researches, Vehicular Technology Conference, 2008. VTC 2008-Fall. IEEE 68th Sept 2008
[16] Shie-Yuan Wang, Chih-Che Lin, NCTUns 6.0: A Simulator for Advanced Wireless Vehicular Network Research, Vehicular Technology Conference, VTC 2010-Spring. IEEE 71st May 2010
[17] NCTUns (EstiNet) Network Simulator Learning guide. online available: http://csie.nqu.edu.tw/smallko/nctuns/nctuns.htm
[18] Ns-3 Tutorial, online available http://www.nsnam.org/docs/tutorial/html
[19] Akhtar Husain, Ram Shringar Raw, Brajesh Kumar, and Amit Doegar, Performance comparison of Topology and Position based Routing Protocols in Vehicular Network Environments, International Journal of Wireless & Mobile Networks (IJWMN) Vol. 3, No. 4, August 2011
[20] Pranav Kumar Singh, Kapang Lego, Dr. Themrichon Tuithung, Simulation based Analysis of Adhoc Routing Protocol in Urban and Highway Scenario of VANET, International Journal of computer Applications (0975-8887) Volume 12-NO.10, Jan 2011
41
[21] Qi Chen, Jiang, D.; Delgrossi, L., IEEE 1609.4 DSRC Multi-Channel Operations and its Implementations on Vehicle Safety communications, Vehicular Networking Conference (VNC), 2009 IEEE, Page: 1-8, 2009
[22] IEEE Std 1609.2 - IEEE Standard for Wireless Access in Vehicular Environments – Security Services for Applications and Management Messages, April 2013
[23] IEEE Std 1609.3 - IEEE Standard for Wireless Access in Vehicular environments (WAVE) – Networking Services, December 2010
[24] IEEE Std 1609.4 - IEEE Standard for Wireless Access in Vehicular environments (WAVE) –Multi-channel Operation, Feb 2011
[25] IEEE Std 802.11p – Amendment 6: Wireless Access in Vehicular Environments, July 2010
[26] whiteoak-ns3-vanet – online available http://code.google.com/r/whiteoak-ns3-vanet/source/browse/protocols
[27] Shie-Yuan Wang and ChihLiang Chou, NCTUns SIMULATOR FOR WIRELESS VEHICULAR AD HOC NETWORK RESEARCH, online http://nsllab.cs.nctu.edu.tw/NSL/NovaVANET.pdf
[28] Hideaki Takagi and Leonard Kleinrock, Optimal Transmission Ranges for Randomly distributed Packet Radio Terminals, IEEE Transactions on Communications, 32(2) Pages 246-257, March 1984
42
Appendix A
Source Code for REACT-DIS with LIMITED-ACK
MYWSMSTACKHELPER.H
#ifndef WSM_STACK_HELPER_H #define WSM_STACK_HELPER_H
#include "ns3/node-container.h" #include "ns3/object.h" #include "ns3/object-factory.h" #include "ns3/wifi-net-device.h" #include "ns3/packet.h" #include "ns3/ptr.h" #include "ns3/header.h" #include "ns3/nstime.h"
//header files for message history #include <vector> #include "ns3/simulator.h"
#include "ns3/random-variable-stream.h"
using namespace ns3;
#define WSMPROTOCOL_ID 0x88DCU #define WSMPROTOCOL_PRIORITY 1U #define WSMPROTOCOL_RANGE 250.0
#define MSG_TIMEOUT 2000 //2000 ms
class MsgHistoryEntry { public: MsgHistoryEntry (uint32_t id=0, uint16_t seqno=0, uint8_t state=0, Time delaytime=Simulator::Now(), uint8_t count=0, Time expiretime=Simulator::Now()) : m_SenderID (id),
m_seqno (seqno), m_hops (0), m_state (state), m_delay (delaytime), m_rx_count (count), m_expiretime (expiretime + MilliSeconds(MSG_TIMEOUT)), m_ackreceived (false)
{ }
uint32_t GetSenderID () const {
43
return m_SenderID; }
uint16_t GetSeqNo() const {
return m_seqno; }
uint8_t GetHops() const {
return m_hops; }
void SetHops(int8_t hops_next_tx) {
m_hops = hops_next_tx; }
int8_t GetState() const {
return m_state; }
void SetState(int8_t state) {
m_state = state; }
int8_t GetRXCount() const {
return m_rx_count; }
void SetRXCount(int8_t pktcount) {
m_rx_count = pktcount; }
Time GetDelayTime() const {
return m_delay; }
void SetDelayTime(Time delaytime) {
m_delay = delaytime; }
Time GetExpireTime() const {
return m_expiretime; }
44
bool GetAckStatus() const {
return m_ackreceived; }
void SetAckStatus() {
m_ackreceived = true; } private: uint32_t m_SenderID; uint16_t m_seqno; uint8_t m_hops; int8_t m_state; Time m_delay; int8_t m_rx_count; Time m_expiretime; bool m_ackreceived; };
class WSMProtocolHeader : public Header { public: WSMProtocolHeader (); virtual ~WSMProtocolHeader ();
static TypeId GetTypeId (void); virtual TypeId GetInstanceTypeId (void) const; virtual void Print (std::ostream &os) const; virtual void Serialize (Buffer::Iterator start) const; virtual uint32_t Deserialize (Buffer::Iterator start); virtual uint32_t GetSerializedSize (void) const;
void SetHeader (uint32_t sender, uint16_t seq_no, uint8_t hops, double x, double y, uint8_t pkttype); void SetHops (uint8_t hops); void SetPosition (double x, double y);
uint32_t GetSender (void) const; uint16_t GetSeqNo (void) const; uint8_t GetHopsLeft (void) const; double GetXPosi(void) const; double GetYPosi(void) const; uint8_t GetPacketType(void) const;
private: uint32_t m_sender; //4 uint16_t m_seq; //2 uint8_t m_hop; //1 double m_x_pos; // double m_y_pos; uint8_t m_acktype; //0-data; 1-ack };
45
class MyWSMStackHelper { public:
MyWSMStackHelper(void);
virtual ~MyWSMStackHelper(void);
void Install(Ptr<Node> node) const; void Install(NodeContainer c) const; void InstallReceiver(Ptr<Node> node) const;
};
class MyWSMStack : public Object { public:
static TypeId GetTypeId(void); static const uint16_t WSM_ID = WSMPROTOCOL_ID;
MyWSMStack(void); virtual ~MyWSMStack(void);
void WSMSend (Ptr<Packet> packet, WSMProtocolHeader header); void WSMReceive (Ptr<NetDevice> device, Ptr<const Packet> packet, uint16_t protocol, const Address& from, const Address& to, NetDevice::PacketType packetType);
void Initialize(Ptr< Node > node); void SetAsReceiver(void); void StackTask(void); //history management void AddMsg(MsgHistoryEntry & MsgEntry); bool FindMsg(MsgHistoryEntry & MsgEntry); void SetMsgHops(uint32_t id, uint16_t seqno, uint8_t hops_next_tx); void SetMsgDelay(uint32_t id, uint16_t seqno, Time delaytime); void IncMsgCount(uint32_t id, uint16_t seqno); void SetMsgState(uint32_t id, uint16_t seqno, int8_t new_state); Time GetMsgDelay(uint32_t id, uint16_t seqno) const; int8_t GetMsgCount(uint32_t id, uint16_t seqno) const; int8_t GetMsgState(uint32_t id, uint16_t seqno) const; bool IsAcked(uint32_t id, uint16_t seqno) const; bool SetAcked(uint32_t id, uint16_t seqno);
private: Ptr<Node> m_node; Ptr<WifiNetDevice> m_NetDevice; double m_wifirange; bool m_Receiver; bool m_relaymode; Time m_relaymode_time; Ptr<UniformRandomVariable> m_random1; Ptr<UniformRandomVariable> m_random2; uint32_t m_maxsize; Time m_task_interval;
46
uint16_t m_currentseq;
//Packet history std::vector<MsgHistoryEntry> m_MsgHistory; void Purge();
};
class MyWSMGenerator : public Object { public:
static TypeId GetTypeId(void); static const uint16_t WSM_ID = WSMPROTOCOL_ID;
MyWSMGenerator(void); virtual ~MyWSMGenerator(void);
void GenReceive(Ptr<NetDevice> device, Ptr<const Packet> packet, uint16_t protocol, const Address& from, const Address& to, NetDevice::PacketType packetType);
void WSMGenerator (void); void WSMGenerator_task(void); void Initialize(Ptr< Node > node);
private: Ptr<Node> m_node; Ptr<WifiNetDevice> m_NetDevice; double m_wifirange; Time m_interval; uint16_t m_seqno; Time m_TimetoGenerateNext; bool m_taskNotStarted; bool m_previouspktacked;
}; #endif //
MYWSMSTACKHELPER.CC
#include "ns3/mywsmstackhelper.h"
#include "ns3/wifi-phy.h" #include "ns3/assert.h" #include "ns3/log.h" #include "ns3/object.h" #include "ns3/packet-socket-factory.h" #include "ns3/config.h" #include "ns3/simulator.h" #include "ns3/string.h" #include "ns3/callback.h" #include "ns3/node.h" #include "ns3/node-list.h"
47
#include "ns3/core-config.h" #include "ns3/position-allocator.h" #include "ns3/mobility-helper.h" #include "ns3/mobility-model.h" #include "ns3/nstime.h" #include "ns3/vector.h" #include <algorithm> //for remove_if #include "ns3/integer.h" using namespace ns3; #define MAX_HOPS 3 //4 hoppings, when hops = 1, it is selective: if ack received, hop, otherwise no hop #define PACKET_SIZE 1000 //2 bytes long #define RELAYING_MODE 0 #define SCHEDULE_MODE 1 #define RELAYED_MODE 2 #define NORELAY_MODE 3 #define REDIAS 180//m #define TIME_MAX 100//ms #define TIME_MIN 60 //ms #define TASK_INTERVAL 1//ms #define MAX_RXCOUNT 4//times #define RELAYMODE_TIME 100//ms #define START_DELAY 1000//ms #define FORWARD_REDUCING_FACTOR 1//represent #define MAX_ACK_COUNT 3//max ack for one seqno sent by receiver #define DATA_PACKET 0 #define ACK_PACKET 1 #define DATA_PACKET_ACKPREVIOUS 2 /**************************************************************** MyWSMStackHelper class Helper for installing WSM stack to a node, a group of nodes or a receiver node *****************************************************************/ MyWSMStackHelper::MyWSMStackHelper() { } MyWSMStackHelper::~MyWSMStackHelper() { } void MyWSMStackHelper::Install(NodeContainer c) const {
48
for (NodeContainer::Iterator i = c.Begin (); i != c.End (); ++i) {
Install (*i); } }
void MyWSMStackHelper::Install(Ptr< Node > node) const { ObjectFactory factory; factory.SetTypeId ("MyWSMStack"); Ptr<MyWSMStack> protocol = factory.Create <MyWSMStack> (); protocol->Initialize(node); node->AggregateObject (protocol); node->RegisterProtocolHandler(MakeCallback (&MyWSMStack::WSMReceive, protocol), MyWSMStack::WSM_ID, 0); /*0 means install to all device*/ }
void MyWSMStackHelper::InstallReceiver(Ptr<Node> node) const { ObjectFactory factory; factory.SetTypeId ("MyWSMStack"); Ptr<MyWSMStack> protocol = factory.Create <MyWSMStack> (); protocol->SetAsReceiver(); protocol->Initialize(node); node->AggregateObject (protocol); node->RegisterProtocolHandler(MakeCallback (&MyWSMStack::WSMReceive, protocol), MyWSMStack::WSM_ID, 0); /*0 means install to all device*/ }
/****************************************************************** WSMProtocolHeader Used to set or get packet header fields, serialize packet header and Deserialize packet header *******************************************************************/ NS_OBJECT_ENSURE_REGISTERED (WSMProtocolHeader);
TypeId WSMProtocolHeader::GetTypeId(void) { static TypeId tid = TypeId("WSMProtocolHeader")
.SetParent<Object> () .AddConstructor<WSMProtocolHeader> () ;
return tid; }
WSMProtocolHeader::WSMProtocolHeader() : m_sender(0),m_seq(0),m_hop(0), m_x_pos(0), m_y_pos(0), m_acktype(0) { }
WSMProtocolHeader::~WSMProtocolHeader() { }
TypeId
49
WSMProtocolHeader::GetInstanceTypeId (void) const { return GetTypeId (); } void WSMProtocolHeader::Print (std::ostream &os) const { os << "senderId=" << m_sender << std::endl; } uint32_t WSMProtocolHeader::GetSerializedSize (void) const { return (8+2*sizeof(double)); } void WSMProtocolHeader::Serialize (Buffer::Iterator start) const { start.WriteHtonU32(m_sender); start.WriteHtonU16(m_seq); start.WriteU8(m_hop); start.WriteU64(m_x_pos); start.WriteU64(m_y_pos); start.WriteU8(m_acktype); } uint32_t WSMProtocolHeader::Deserialize (Buffer::Iterator start) { m_sender = start.ReadNtohU32(); m_seq = start.ReadNtohU16(); m_hop = start.ReadU8(); m_x_pos = double(start.ReadU64()); m_y_pos = double(start.ReadU64()); m_acktype = start.ReadU8(); return GetSerializedSize(); } uint8_t WSMProtocolHeader::GetPacketType(void) const { return m_acktype; } void WSMProtocolHeader::SetHeader (uint32_t sender, uint16_t seq_no, uint8_t hops, double x, double y, uint8_t pkttype) { m_sender = sender; m_seq = seq_no;
50
m_hop = hops; m_x_pos = x; m_y_pos = y; m_acktype = pkttype; //is data message }
void WSMProtocolHeader::SetHops (uint8_t hops) { m_hop = hops; }
void WSMProtocolHeader::SetPosition (double x, double y) { m_x_pos = x; m_y_pos = y; }
uint32_t WSMProtocolHeader::GetSender (void) const { return m_sender;
}
uint16_t WSMProtocolHeader::GetSeqNo (void) const { return m_seq; }
uint8_t WSMProtocolHeader::GetHopsLeft (void) const { return m_hop; }
double WSMProtocolHeader::GetXPosi(void) const { return m_x_pos; }
double WSMProtocolHeader::GetYPosi(void) const { return m_y_pos; }
51
/********************************************************************** WSMStack class The stack contains the function required for REACT-DIS with limited ACK protocol, including 1. WSM receiving2. WSM send3. 1 ms WSM periodical task4. WSM message history management***********************************************************************/ NS_OBJECT_ENSURE_REGISTERED (MyWSMStack); NS_LOG_COMPONENT_DEFINE ("MyWSMStack");
TypeId MyWSMStack::GetTypeId(void) { static TypeId tid = TypeId("MyWSMStack")
.SetParent<Object> () .AddConstructor<MyWSMStack> () ;
return tid; }
MyWSMStack::MyWSMStack(): m_wifirange(250.0), m_Receiver(false), m_relaymode(false), m_relaymode_time(MilliSeconds(0)), m_maxsize(255), m_task_interval(MilliSeconds(TASK_INTERVAL)), m_currentseq(0){ }
MyWSMStack::~MyWSMStack() { }
void MyWSMStack::WSMSend(Ptr< Packet > packet, WSMProtocolHeader header) { NS_ASSERT (m_node != 0); NS_LOG_DEBUG("@" << Simulator::Now() << " [MyWSMStack::WSMSend] NodeId=" << m_node->GetId()); packet->RemoveAllPacketTags();
packet->AddHeader(header);
m_NetDevice->Send(packet, m_NetDevice->GetBroadcast(), MyWSMStack::WSM_ID); }
void MyWSMStack::WSMReceive(Ptr<NetDevice> device, Ptr<const Packet> packet, uint16_t protocol, const Address& from, const Address& to, NetDevice::PacketType packetType) {
NS_ASSERT (protocol == MyWSMStack::WSM_ID); NS_ASSERT (device->GetNode() == m_node);
Ptr<Packet> newPacket = packet->Copy(); WSMProtocolHeader header; newPacket->RemoveHeader(header);
52
Ptr<MobilityModel> model= m_node ->GetObject<MobilityModel>(); Vector temp = model->GetPosition(); static uint8_t ack_count; if (m_Receiver) { std::cout<<"RECEIVER : Node"<<m_node->GetId()<<"received packet " <<uint16_t(header.GetSeqNo()) << " with hops " <<uint16_t(header.GetHopsLeft()) << " at "<<temp.x << " "<<temp.y <<" from "<<header.GetXPosi()<<" "<<header.GetYPosi()<<"\n"; if(header.GetSeqNo()>m_currentseq) { WSMProtocolHeader newheader; newheader.SetHeader(header.GetSender(),header.GetSeqNo(), 0, temp.x,temp.y, ACK_PACKET); Ptr<Packet> packet = Create<Packet> (1); WSMSend(packet,newheader); std::cout<<"RECEIVER : Node"<<m_node->GetId()<<"send ack packet " <<uint16_t(header.GetSeqNo()) << " with hops " <<uint16_t(header.GetHopsLeft()) << " at "<<temp.x << " "<<temp.y <<" "<<Simulator::Now()<<"\n"; m_currentseq = header.GetSeqNo() ; ack_count=1; } else if(header.GetSeqNo()==m_currentseq && ack_count < MAX_ACK_COUNT) { WSMProtocolHeader newheader; newheader.SetHeader(header.GetSender(),header.GetSeqNo(), 0, temp.x,temp.y, ACK_PACKET); Ptr<Packet> packet = Create<Packet> (1); WSMSend(packet,newheader); std::cout<<"RECEIVER : Node"<<m_node->GetId()<<"send ack packet " <<uint16_t(header.GetSeqNo()) << " with hops " <<uint16_t(header.GetHopsLeft()) << " at "<<temp.x << " "<<temp.y<<" "<<Simulator::Now() <<"\n"; m_currentseq = header.GetSeqNo() ; ack_count++; } } else { MsgHistoryEntry NewMsg(header.GetSender(),header.GetSeqNo(),NORELAY_MODE, Simulator::Now(), 1, Simulator::Now()); if (header.GetPacketType() == DATA_PACKET ||header.GetPacketType() == DATA_PACKET_ACKPREVIOUS ) { if (header.GetPacketType() == DATA_PACKET_ACKPREVIOUS ) { SetMsgState(header.GetSender(),header.GetSeqNo()-1,NORELAY_MODE);
53
m_currentseq=header.GetSeqNo(); } if (FindMsg(NewMsg)) { IncMsgCount(header.GetSender(),header.GetSeqNo()); } else { AddMsg(NewMsg); uint8_t hops = header.GetHopsLeft(); if (hops > 0) { SetMsgHops(header.GetSender(),header.GetSeqNo(),hops-1); if(hops >1 || (hops == 1 && (IsAcked(header.GetSender(),header.GetSeqNo()-1) == true || IsAcked(header.GetSender(),header.GetSeqNo()-2) == true))) { Time delay; if (m_relaymode) { Ptr<UniformRandomVariable> temp_rand=CreateObject<UniformRandomVariable>(); //choose a random delay delay = MilliSeconds(temp_rand->GetInteger(20, 40)); SetMsgDelay(header.GetSender(),header.GetSeqNo(),delay + Simulator::Now()); //set status to relaying SetMsgState(header.GetSender(),header.GetSeqNo(),RELAYING_MODE); } else { //Calculate distance double dist; dist = CalculateDistance(Vector(header.GetXPosi(),header.GetYPosi(),0.0), temp); //Decide delay time if (dist >= REDIAS) { delay = MilliSeconds(TIME_MIN); } else { delay = MilliSeconds((1-dist/REDIAS)*(TIME_MAX-TIME_MIN)+TIME_MIN); } SetMsgDelay(header.GetSender(),header.GetSeqNo(),delay + Simulator::Now()); //set status to scheduled SetMsgState(header.GetSender(),header.GetSeqNo(),SCHEDULE_MODE); if (header.GetSeqNo()==220)
54
std::cout << "Node "<<m_node->GetId()<<" schedule "<<(delay+Simulator::Now())<<"\n";
}//check relaymode } else { SetMsgState(header.GetSender(),header.GetSeqNo(),NORELAY_MODE);
} } else {
SetMsgState(header.GetSender(),header.GetSeqNo(),NORELAY_MODE); }
}//message found }//acktype=0 else {//ack type packet
if (SetAcked(header.GetSender(),header.GetSeqNo())==false) {/*ackreceived first*/ NewMsg.SetRXCount(0); AddMsg(NewMsg);
} if (header.GetSeqNo()>m_currentseq) m_currentseq=header.GetSeqNo()+1
} }//end of regular node }
void MyWSMStack::Initialize(Ptr< Node > node) { m_node = node; m_NetDevice = node->GetDevice(0)->GetObject<WifiNetDevice>();
Simulator::Schedule(MilliSeconds(START_DELAY), &MyWSMStack::StackTask, this ); }
void MyWSMStack::SetAsReceiver(void) { m_Receiver = true; }
void MyWSMStack::StackTask(void) { if (m_relaymode) {
if (m_relaymode_time > Simulator::Now()) {
m_relaymode = false; }
} //schedule through each message for (std::vector<MsgHistoryEntry>::iterator i = m_MsgHistory.begin (); i
!= m_MsgHistory.end (); ++i)
55
{ switch(i->GetState()) { case RELAYING_MODE: if (i->GetDelayTime() < Simulator::Now()) { Ptr<UniformRandomVariable> temp_rand=CreateObject<UniformRandomVariable>(); if (i->GetRXCount()<=MAX_RXCOUNT || ((10>(i->GetRXCount()-MAX_RXCOUNT)*FORWARD_REDUCING_FACTOR) && (uint16_t(temp_rand->GetInteger(1, 10))>(i->GetRXCount()-MAX_RXCOUNT)*FORWARD_REDUCING_FACTOR))) { if(i->GetAckStatus()==false || i->GetSeqNo()>=m_currentseq) { Vector temp = m_node ->GetObject<MobilityModel>()->GetPosition(); WSMProtocolHeader header; header.SetHeader(i->GetSenderID(),i->GetSeqNo(), i->GetHops(), temp.x,temp.y, DATA_PACKET); Ptr<Packet> packet = Create<Packet> (PACKET_SIZE);/*2 bytes payload*/ WSMSend(packet,header); } //set to relayed i->SetState(RELAYED_MODE); } else { i->SetState(NORELAY_MODE); } } break; case SCHEDULE_MODE: if (i->GetDelayTime() < Simulator::Now()) { uint16_t maxRange = pow(10, (i->GetRXCount()-1)); Ptr<UniformRandomVariable> temp_rand=CreateObject<UniformRandomVariable>(); uint32_t temp; if (maxRange >= 1) { temp = temp_rand->GetInteger(1,maxRange); } else { temp = 0; } if((i->GetRXCount() == 1) || (i->GetRXCount()<=MAX_RXCOUNT && temp == 1))
56
{ if(i->GetAckStatus()==false || i->GetSeqNo()>=m_currentseq) {//send Vector temp = m_node ->GetObject<MobilityModel>()->GetPosition(); WSMProtocolHeader header; header.SetHeader(i->GetSenderID(),i->GetSeqNo(), i->GetHops(), temp.x,temp.y,DATA_PACKET); Ptr<Packet> packet = Create<Packet> (PACKET_SIZE); WSMSend(packet,header); } //set to relayed i->SetState(RELAYED_MODE); //Set relaynode m_relaymode = true; //set relay node time m_relaymode_time = Simulator::Now()+MilliSeconds(RELAYMODE_TIME); } else { // set to norelay i->SetState(NORELAY_MODE); } } break; case RELAYED_MODE: break; case NORELAY_MODE: break; default: break; } } Simulator::Schedule(MilliSeconds(1)/*m_task_interval*/, &MyWSMStack::StackTask, this ); } void MyWSMStack::AddMsg(MsgHistoryEntry & MsgEntry) { Purge(); if (m_MsgHistory.size() >= m_maxsize) { m_MsgHistory.erase (m_MsgHistory.begin()); //drop the oldest message } m_MsgHistory.push_back(MsgEntry); } bool
57
MyWSMStack::FindMsg(MsgHistoryEntry & MsgEntry) { Purge();
for (std::vector<MsgHistoryEntry>::const_iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i)
{ if ((i->GetSenderID () == MsgEntry.GetSenderID ()) && (i->GetSeqNo () == MsgEntry.GetSeqNo ()))
{ return true;
} } return false; }
void MyWSMStack::SetMsgHops(uint32_t id, uint16_t seqno, uint8_t hops_next_tx) { for (std::vector<MsgHistoryEntry>::iterator i = m_MsgHistory.begin (); i
!= m_MsgHistory.end (); ++i) {
if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) {
i->SetHops(hops_next_tx); return;
} } }
void MyWSMStack::SetMsgDelay(uint32_t id, uint16_t seqno, Time delaytime) { for (std::vector<MsgHistoryEntry>::iterator i = m_MsgHistory.begin (); i
!= m_MsgHistory.end (); ++i) {
if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) {
i->SetDelayTime(delaytime); return;
} } }
void MyWSMStack::IncMsgCount(uint32_t id, uint16_t seqno) { int8_t pktcount;
for (std::vector<MsgHistoryEntry>::iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i)
{ if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno))
58
{ pktcount = i->GetRXCount()+1; i->SetRXCount(pktcount); return; } } } void MyWSMStack::SetMsgState(uint32_t id, uint16_t seqno, int8_t new_state) { for (std::vector<MsgHistoryEntry>::iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i) { if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) { i->SetState(new_state); return; } } } Time MyWSMStack::GetMsgDelay(uint32_t id, uint16_t seqno) const { for (std::vector<MsgHistoryEntry>::const_iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i) { if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) { return (i->GetDelayTime()); } } return (Time(0)); } int8_t MyWSMStack::GetMsgCount(uint32_t id, uint16_t seqno) const { for (std::vector<MsgHistoryEntry>::const_iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i) { if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) { return (i->GetRXCount()); } } return (-1); } int8_t MyWSMStack::GetMsgState(uint32_t id, uint16_t seqno) const {
59
for (std::vector<MsgHistoryEntry>::const_iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i) { if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) { return (i->GetState()); } } return (-1); } bool MyWSMStack::IsAcked(uint32_t id, uint16_t seqno) const { for (std::vector<MsgHistoryEntry>::const_iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i) { if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) { return (i->GetAckStatus()); } } return (false); } bool MyWSMStack::SetAcked(uint32_t id, uint16_t seqno) { for (std::vector<MsgHistoryEntry>::iterator i = m_MsgHistory.begin (); i != m_MsgHistory.end (); ++i) { if ((i->GetSenderID () == id) && (i->GetSeqNo () == seqno)) { i->SetAckStatus(); return true; } } return false; } struct MsgExpired { bool operator() (MsgHistoryEntry const & entry) const { return (entry.GetExpireTime() < Simulator::Now()); } }; void MyWSMStack::Purge() { MsgExpired pred;
60
m_MsgHistory.erase (std::remove_if(m_MsgHistory.begin(), m_MsgHistory.end(), pred), m_MsgHistory.end()); }
/******************************************************************************** WSMGenerator class A special class for packet generator to 1. receive ack message2. generate and transmit WSM packet3. 10ms periodical task********************************************************************************/ NS_OBJECT_ENSURE_REGISTERED (MyWSMGenerator);
TypeId MyWSMGenerator::GetTypeId(void) { static TypeId tid = TypeId("MyWSMGenerator")
.SetParent<Object> () .AddConstructor<MyWSMGenerator> () ;
return tid; }
MyWSMGenerator::MyWSMGenerator(): m_wifirange(250.0), m_interval(MilliSeconds(95)), m_seqno(0), m_TimetoGenerateNext(Simulator::Now()), m_taskNotStarted(true), m_previouspktacked(false) { } //transmission interval is 10ms
MyWSMGenerator::~MyWSMGenerator() { }
void MyWSMGenerator::GenReceive(Ptr<NetDevice> device, Ptr<const Packet> packet, uint16_t protocol, const Address& from, const Address& to, NetDevice::PacketType packetType) {
NS_ASSERT (protocol == MyWSMStack::WSM_ID); NS_ASSERT (device->GetNode() == m_node);
Ptr<Packet> newPacket = packet->Copy();
WSMProtocolHeader header; newPacket->RemoveHeader(header);
if (header.GetPacketType() == 1 && (header.GetSeqNo()+1) == m_seqno)/*0 is regular, 1 is ack packet*/ { std::cout<<"GENERATOR : ACK received for "<<uint16_t(header.GetSeqNo())<<" at "<<Simulator::Now() << "by "<< m_node->GetId()<<"\n";
m_previouspktacked=true; WSMGenerator(); m_TimetoGenerateNext = MilliSeconds(100)+Simulator::Now(); if(m_taskNotStarted == true) {
61
Simulator::Schedule(MilliSeconds(10), &MyWSMGenerator::WSMGenerator_task, this ); m_taskNotStarted = false; } } } void MyWSMGenerator::WSMGenerator() { NS_ASSERT (m_node != 0); NS_LOG_DEBUG("@" << Simulator::Now() << " [MyWSMStack::WSMSend] NodeId=" << m_node->GetId()); Vector temp = m_node ->GetObject<MobilityModel>()->GetPosition(); WSMProtocolHeader header; if (m_previouspktacked) header.SetHeader(m_node->GetId(),m_seqno, MAX_HOPS, temp.x, temp.y, DATA_PACKET_ACKPREVIOUS); else header.SetHeader(m_node->GetId(),m_seqno, MAX_HOPS, temp.x, temp.y, DATA_PACKET); Ptr<Packet> packet = Create<Packet> (PACKET_SIZE); /*PACKET_SIZE bytes payload*/ packet->AddHeader(header); m_NetDevice->Send(packet, m_NetDevice->GetBroadcast(), WSM_ID); std::cout<<"GENERATOR : packet "<<uint16_t(m_seqno)<<" generated at: "<<Simulator::Now() <<" at "<<temp.x << " "<< temp.y<< "by "<< m_node->GetId()<<"\n"; m_previouspktacked=false; m_seqno++; } void MyWSMGenerator::WSMGenerator_task() { if (m_TimetoGenerateNext<Simulator::Now()) { WSMGenerator(); m_TimetoGenerateNext = MilliSeconds(100)+Simulator::Now(); } Simulator::Schedule(MilliSeconds(10), &MyWSMGenerator::WSMGenerator_task, this ); } void MyWSMGenerator::Initialize(Ptr< Node > node) { m_node = node; m_NetDevice = node->GetDevice(0)->GetObject<WifiNetDevice>();
62
m_node->RegisterProtocolHandler(MakeCallback (&MyWSMGenerator::GenReceive, this), MyWSMGenerator::WSM_ID, 0);
m_seqno=1; //first packet is 1 Simulator::Schedule(MilliSeconds(START_DELAY), &MyWSMGenerator::WSMGenerator, this ); }
WAVE-PROJECT.CC
#include "ns3/vector.h" #include "ns3/string.h" #include "ns3/socket.h" #include "ns3/double.h" #include "ns3/config.h" #include "ns3/log.h" #include "ns3/command-line.h" #include "ns3/constant-velocity-mobility-model.h" #include "ns3/mobility-model.h" #include "ns3/yans-wifi-helper.h" #include "ns3/position-allocator.h" #include "ns3/mobility-helper.h" #include <iostream>
#include "ns3/ocb-wifi-mac.h" #include "ns3/wifi-80211p-helper.h" #include "ns3/wave-mac-helper.h" #include "ns3/netanim-module.h" /*for netenim*/ #include "ns3/packet-metadata.h"
#include "ns3/mywsmstackhelper.h"
NS_LOG_COMPONENT_DEFINE ("WaveProject"); using namespace ns3;
#define ENDTIME 15.0
static void GenerateTraffic (Ptr<Socket> socket, uint32_t pktSize, uint32_t pktCount, Time pktInterval )
{ if (pktCount > 0) {
socket->Send (Create<Packet> (pktSize)); Simulator::Schedule (pktInterval, &GenerateTraffic,
socket, pktSize,pktCount - 1, pktInterval); } else {
socket->Close (); } }
63
int main (int argc, char *argv[]) { uint16_t num_node_one_row = 16; //16 nodes each row at background uint16_t num_row = 16; //16 row at background double node_distance = 50.0; //distance between two nodes is 50 uint16_t numberofbackground = num_node_one_row * num_row; Vector CenterPosi (375, 375, 0); Vector Gen_Vel (25, 25, 0); Vector Rec_Vel (-25, -25, 0);
uint16_t Cutoffrange = 250; uint32_t packetSize = 1000; // bytes uint32_t numPackets = 1; double interval = 1.0; // seconds bool verbose = false;
CommandLine cmd;
cmd.AddValue ("packetSize", "size of application packet sent", packetSize); cmd.AddValue ("numPackets", "number of packets generated", numPackets); cmd.AddValue ("interval", "interval (seconds) between packets", interval); cmd.AddValue ("verbose", "turn on all WifiNetDevice log components", verbose); cmd.Parse (argc, argv); // Convert to time object Time interPacketInterval = Seconds (interval);
NodeContainer background; background.Create (numberofbackground);
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default (); YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default (); wifiChannel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel"); wifiChannel.AddPropagationLoss ("ns3::RangePropagationLossModel", "MaxRange", DoubleValue(Cutoffrange)); Ptr<YansWifiChannel> channel = wifiChannel.Create (); wifiPhy.SetChannel (channel);
NqosWaveMacHelper wifi80211pMac = NqosWaveMacHelper::Default (); Wifi80211pHelper wifi80211p = Wifi80211pHelper::Default (); if (verbose) {
wifi80211p.EnableLogComponents (); // Turn on all Wifi 802.11p logging }
wifi80211p.SetRemoteStationManager ("ns3::ConstantRateWifiManager"/*, "DataMode",StringValue (phyMode), "ControlMode",StringValue (phyMode)*/);
NetDeviceContainer devices = wifi80211p.Install (wifiPhy, wifi80211pMac, background);
MobilityHelper mobility;
64
Ptr<ListPositionAllocator> positionAlloc = CreateObject<ListPositionAllocator> (); for (int i=0; i<num_node_one_row; i++) { for (int j=0; j<num_row; j++) { positionAlloc->Add (Vector (j*node_distance, i*node_distance, 0.0)); } } mobility.SetPositionAllocator (positionAlloc); mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); mobility.Install (background); MyWSMStackHelper MyWSMStack; MyWSMStack.Install (background); //create receiver Ptr<Node> PktReceiver = CreateObject<Node>(); devices.Add(wifi80211p.Install(wifiPhy, wifi80211pMac, PktReceiver)); MobilityHelper RecMobile; RecMobile.SetMobilityModel("ns3::ConstantVelocityMobilityModel"); RecMobile.Install(PktReceiver); PktReceiver->GetObject<MobilityModel> ()->SetPosition(CenterPosi); PktReceiver->GetObject<ConstantVelocityMobilityModel> ()->SetVelocity(Rec_Vel); MyWSMStackHelper WSMReceiver; WSMReceiver.InstallReceiver (PktReceiver); //create and install traffic generator Ptr<Node> PktGenerator = CreateObject<Node>(); devices.Add(wifi80211p.Install(wifiPhy, wifi80211pMac, PktGenerator)); MobilityHelper GenMobile; GenMobile.SetMobilityModel("ns3::ConstantVelocityMobilityModel"); GenMobile.Install(PktGenerator); PktGenerator->GetObject<MobilityModel> ()->SetPosition(CenterPosi); PktGenerator->GetObject<ConstantVelocityMobilityModel> ()->SetVelocity(Gen_Vel); ObjectFactory factory; factory.SetTypeId ("MyWSMGenerator"); Ptr<MyWSMGenerator> protocol = factory.Create <MyWSMGenerator> (); PktGenerator->AggregateObject (protocol); PktGenerator->GetObject<MyWSMGenerator> ()->Initialize(PktGenerator); Simulator::Stop(Seconds(ENDTIME)); AnimationInterface anim ("wave_project.xml"); // Mandatory anim.SetMaxPktsPerTraceFile(1000000); for (int i=0; i<numberofbackground; i++) {
65
Vector temp = background.Get(i)->GetObject<MobilityModel> ()->GetPosition(); anim.SetConstantPosition(background.Get(i), temp.x, temp.y );
}
anim.SetMobilityPollInterval(Seconds(0.01));
wifiPhy.EnablePcapAll("WaveProj");
Simulator::Run (); Simulator::Destroy ();
return 0; }