Vanet Traffic Report All Re

CHAPTER 1
INTRODUCTION
1.1INTRODUCTION
Computer Network was always the key element of today’s technological advancement. In
previous chapter a brief introduction and detail project outline were discussed. This chapter is
aim to provide an initial of overview of Vehicular Ad-hoc network, which is the topic area for this
research and also a literature analysis will be carried out containing similar previous research
materials and outcomes of those researches.
VANET is a particular case of wireless multihop network, which has the constraint of fast
topology changes due to the high node mobility. With the increasing number of vehicles equipped
with computing technologies and wireless communication devices, intervehicle communication
is becoming a promising field of research, standardization, and development. VANETs enable a
wide range of applications, such as prevention of collisions, safety, blind crossing, dynamic route
scheduling, real-time traffic condition monitoring, etc. Another important application for
VANETs is providing Internet connectivity to vehicular nodes.
1.2ABOUT THE DOMAIN
1.2.1 VEHICULAR AD-HOC NETWORK (VANET)
Vehicular Ad-hoc Network is a term which describes an infrastructure less network

consisting of both fixed node and Vehicular nodes exchange data with each other without any
centralised infrastructure or base station. An as a result transitional node behaves like router to
transmit data to nodes not in range. The technology is so far very sophisticated and for its dynamic
nature as well as the mobility, it’s regarded as one of the most challenging network to design and
deploy. Routing in Vehicular Ad-hoc Network (VANET) is more complicated than the traditional
wired network because the topology changes and the mobility of the nodes make it more difficult
to route the transmission. As a result the VANET is considered one of the most expensive
networks, and makes it critically unusable within public network structure. VANET is widely
1
used in Defence networks, Search and Rescue operation for example a soldier transfers
information about the situation in battlefield or a rescue operation passing detail information from
flood or hurricane affected area. VANET does not contain any infrastructure and each node within
the network acts as a router to form their own network, with these characteristics VANET
networks sometimes called infrastructure less network.
Vehicular Ad-hoc Network has a number of protocols for difference types of VANET. These
protocols are classified as Reactive, Proactive and Hybrid1.
Traffic congestion on the roads is today a large problem in big cities. The congestion and related
vehicle accommodation problem is accompanied by a constant threat of accidents as well.
Absence of road traffic safety takes a toll of precious human lives and poses a dire threat to our
environment as well. Other negative consequences are related to energy waste and environmental
pollution. According to National Highway Traffic Safety Administration, the following figures
indicate some of the consequences of recent car accidents.
• 6.3 million Police reported traffic accidents
• 43,000 people were killed
• Millions of people were injured
• The economy effects caused due to these accidents were more than $230 billion
Preliminary precautions like seat belts and airbags are used but they cannot eliminate problems
due to driver’s inability to foresee the situation ahead of time [14]. On a highway a vehicle cannot
currently predict the speed of other vehicles. However, with use of sensor, computer and wireless
communication equipment, speed could be predicted and a warning message sent every 0.5
seconds could limit the risk of potential accidents [3]. Wireless communication is ubiquitous
because of its flexibility to adapt to different scenarios. Mobile Ad Hoc Networks (MANETS) is
a term coined for the continuously varying network topology handheld mobiles devices.
Vehicular Ad Hoc Networks (VANETS) is one of its types. It deploys the concept of continuously
varying vehicular motion. The nodes or vehicles as in VANETS can move around with no
2
boundaries on their direction and speed. This arbitrary motion of vehicles poses new challenges
to researchers in terms of designing a protocol set more specifically for VANETS. Tests are being
carried out through simulated environments to check the way VANETS perform, before they are
used in commercial application in the real world.
This thesis aims at presenting and analysing the shortcomings of current simulators aimed at or
useful for VANETS. One of them would be chosen for test under certain environmental situations
to check the simulations.
1.2.2 FEATURES OF VANET
• The nodes in a VANET are vehicles and road side units

• The movement of these nodes is very fast
• The motion patterns are restricted by road topology
• Vehicle acts as transceiver i.e. sending and receiving at the same time while creating a highly
dynamic network, which is continuously changing.
• The vehicular density varies from time to time for instance their density might increase during
peak office hours and decrease at night times.
1.2.3 VANET Simulation Problem
To evaluate VANET protocols and services, the first step is to perform an outdoor
experiment. Many wireless technologies such as GPRS, IEEE 802.11p and IEEE 802.16 have
been proposed for reliable traffic information. Before the technology hits the ground and can
meet the expectations, a series of experiments should be performed to test it. These experiments
could be expensive and highly complex to inherit all kinds of situation. For this purpose software
simulations can play a vital role in imitating real world scenarios. VANET relies on and is related
to two other simulations for its smooth functioning, namely traffic simulation and network
simulation. Network simulators are used to evaluate network protocols and application in a
variety of conditions. The traffic simulators are used for transportation and traffic engineering.
These simulations work independently but to satisfy the need of VANET, a solution is required
to use these simulators together. Numerous traffic and network simulations have been tried to
resolve the issues with VANET but every solution has had its shortcomings. There are a large
3
number of traffic and network simulator and they need to be used together into what can be called
VANET simulator. There are few tools for VANET simulation but most of them have the problem
of proper ‘interaction’. Thus a proper selection of a simulator is also a question for simulation.
Therefore, we will debate on present tools and will suggest the choice with proper ‘interaction’.
In this thesis we present NCTUns (National Chiao Tung University) [32] simulator, a powerful
network and traffic simulator freely available for the research community. NCTUns replaced
Harvard simulators in 2002 and after the release of version 4, it greatly supports the simulation
of ITS (Intelligent Transpiration System) network.
‘VEHICULAR ad hoc networks’ (VANETs) are self-configuring networks where the

nodes are vehicles (equipped with on-board computers), elements of roadside infrastructure,
sensors, and pedestrian personal devices. Wi-Fi (IEEE 802.11 based) technologies are used for
deploying such kind of networks. At present, the IEEE group is completing the IEEE 802.11p
and IEEE 1609 final drafts, known as “Standard Wireless Access in Vehicular Environments”
(WAVE), specifically designed for VANETs. This technology presents the opportunity to develop
powerful car systems capable of gathering, processing, and distributing information. For
example, a driver assistance system could collect accurate and up-to-date data about the
surrounding environment, detect potentially dangerous situations, and notify the driver.
In VANETs, the Wi-Fi limitations in coverage and capacity of the channel, the high
mobility of the nodes, and the presence of obstacles generate packet loss, frequent topology
changes, and network fragmentation. Thus, a great deal of effort is dedicated to offer new MAC
access strategies and to design efficient routing protocols. In turn, in such kind of networks,
routing is a challenging task, since there is no central entity in charge of finding the routing paths
among the nodes. Different routing strategies have been defined based on prior ad hoc network
architectures by targeting the specific VANET needs of scenarios and applications. These
protocols can be grouped into: topology-based (proactive -e.g., DSDV and OLSR-, reactive -e.g.,
AODV and DSR-, carry-and forwarding, etc.), position-based (e.g., GPSR and GPCR), cluster-
based (e.g., COIN and LORA CBF), and broadcasting (e.g., BROADCOMM and HV-TRADE)
protocols.
Most of VANET applications critically rely on routing protocols. Thus, an optimal routing
strategy, that makes better use of resources, is crucial to deploy efficient VANETs that actually
4
work in volatile networks. Finding well-suited parameter configurations of existing mobile ad
hoc network protocols is a way of improving their performance, even making the difference
between a network that does work or does not, e.g. the networks with high routing load suffer
from congestion and cannot ensure timely and reliable delivery of messages.
In the present work, we aim at defining and solving an off-line optimization problem in
order to efficiently and automatically tune OLSR, a widely used mobile ad hoc network unicast
proactive routing protocol. Although specific routing protocols are emerging for VANET
networks, a number of authors are currently using OLSR to deploy vehicular networks. This
protocol has been chosen mainly because it presents a series of features that make it well-suited
for VANETs: it exhibits very competitive Parking Delays in the transmission of data packets in
large networks (that is an important feature for VANET applications), it adapts well to the
continuous topology changes, and OLSR has simple operation that allows it to be easily
integrated into different kinds of systems. More details about the use of OLSR in VANETs are
provided in the following section.
However, the continuous exchange of routing control packets causes the appearance of
network congestion, then limiting the global performance of the VANET. Thus, the quality-of-
service (QoS) of OLSR significantly depends on the selection of its parameters, what determine
the protocol operation. As shown in the results presented in and in the present study, OLSR has a
wide range of improvement by changing the configuration parameters. Therefore, computing an
optimal configuration for the parameters of this protocol is crucial before deploying any VANET,
since it could decisively improve the QoS, with a high implication on enlarging the network data
rates and reducing the network load. Then, all these features make OLSR a good candidate to be
optimally tuned.
In this work, we define an optimization problem in order to tune OLSR protocol obtaining
automatically the configuration that best fits the specific characteristics of VANETs. An
optimization problem is defined by a search space and a quality or fitness function. The search
space restricts the possible configurations of a solution vector, which is associated with a
numerical cost by the fitness function. Thus, solving an optimization problem consists in finding
the least-cost configuration of a solution vector. In spite of the moderate number of configurable
parameters that govern OLSR, the number of possible combinations of values that they can take
makes this task very hard.
5
Due to the high complexity that this kind of problems usually shows, the use of automatic
intelligent tools is a mandatory requirement when facing them. In this sense, metaheuristic
algorithms emerge as efficient stochastic techniques able to solve optimization problems. Indeed,
these algorithms are currently employed in a multitude of engineering problems showing a
successful performance. Unfortunately, the use of metaheuristics in the optimization of ad hoc
networks (and concretely in VANETs) is still limited, and just a few related approaches can be
found in the literature.
In Alba et al. a specialized Cellular Multi-Objective Genetic Algorithm (cMOGA) was
used for finding an optimal broadcasting strategy in urban mobile ah hoc networks (MANETs).
In Dorronsoro et al. (2008), six versions of a GA (panmictic and descentralized) were evaluated
and used in the design of ad hoc injection networks. A Genetic Algorithm was also employed by
Cheng et al. [18] for solving the multicast routing problem in MANETs. Due to its specific design,
Shokrani et al. [19] developed new routing protocols for MANETs based on Ant Colony
Optimization (ACO). Particle Swarm Optimization (PSO) algorithm has been used to manage the
network resources by Huang et al. proposing a new routing protocol based on this algorithm to
make scheduling decisions for reducing the packet loss rate in a theoretical VANET scenario.
More recently, Garc´ıa-Nieto et al. optimized the file transfer service (VDTP protocol) in realistic
VANET scenarios (urban and highway) by using different metaheuristic techniques.
We here evaluate four different techniques: Particle Swarm Optimization (PSO),
Differential Evolution (DE), Genetic Algorithm (GA), and Simulated Annealing (SA). We have
chosen these algorithms because they represent a wide and varied set of solvers for real parameter
optimization, based in different search/optimization schemes and strategies. The popular network
simulator ns-2 is used in the fitness function evaluation of the solutions (tentative OLSR
parameters) generated by the optimization algorithms to guide the search process. A set of
VANET instances have been defined by using real data (roads specification and mobility)
concerning a urban area of the city of M´alaga, in Spain.
In summary, the main contributions of this work are:
1) Proposing an optimization strategy in which a number of metaheuristic algorithms are
(separately) coupled with a network simulator (ns-2) to find quasi-optimal solutions.
6
2) This optimization strategy is used in this work to find as fine-tuned as possible configuration
parameters of the OLSR protocol, although it could be directly used also for a number of other
routing protocols (AODV, PROAODV, GPSR, FSR, DSR, etc.).
3) Obtaining OLSR configurations automatically that outperforms the standard one and those used
by human experts in the current state-of-the-art.
4) Generating a set of realistic VANET scenarios based in real area of M´alaga (Spain). These
instances are publicly available online for the sake of future experiments.
The remainder of this paper is organized as follows. In the next section, the OLSR routing
protocol is introduced. Section III describes the optimization design followed to tackle the
problem. Section IV presents the experiments carried out. Results, comparisons, and analyses are
shown in Section V. Finally, conclusions and future work are drawn in Section VI.
1.3 SCOPE OF THE PROJECT

To reduce the delay and maintain the Quality of information in Vehicular Communication
by introducing priority based queuing algorithm for Emergency vehicle Delay Reduction.
1.4 ORGANIATION OF THE CHAPTER

The report is organized as follow:
The directed study phase report is divided into TEN chapters.
Chapter 2: Literature Survey
This chapter describes about the survey of the project related paper. It also comprise of merits
and drawback of the papers.
Chapter 3: Existing System`
In this chapter the general survey is explained followed by the challenges of the existing system
and draw backs of existing system.
Chapter 4: Proposed System
This chapter descries the problem definition and description of each and every modules and
module diagram to represent the modules in detail.
Chapter 5: Module Description
This chapter describes about modules and modules description.
Chapter 6: System Design
7
This chapter describes the problem definition and description of each and every modules and
module diagram to represent the modules in details.
Chapter 6: System Requirements
This chapter describes the hardware and software requirements for the projects.
Chapter 7: Coding
This chapter describes about the coding part.
Chapter 8: Testing
This chapter describes about the testing process of the system.
Chapter 9: Performance Evaluation
In this chapter, it is explain about the performance of the proposed system using simulation
graph.
Chapter 9: Conclusion and Future Enhancement
The conclusion of report is present in this chapter. It also specifies the enhancements that could
be done in days yet to come.
8
CHAPTER 2
LITERATURE SURVEY
The section explores the initial developments that were carried in creating a simulator that
was aimed at testing VANET. Furthermore, the background work in the whole project has also
been presented.
2.1 GrooveSim Network Simulation
GrooveSim [40] was the first tool created for evaluation of VANET performance mainly
motivated by vehicular traffic flow and forecasting. The concept of application involves testing
the possibilities of real time events as time-critical safety messages. GrooveSim was coded in
C++ and Matlab provides GUI for drawing structures and graphs. GrooveSim could operate in
five different modes: predetermined, on-road, simulation, hybrid, research. A group of five
vehicles travelling around the city and highway were simulated for recording certain parameters
like message penetration, Parking Delay, vehicle grouping, packets dropped etc and packet time
to live values were calculated in the simulator. GrooveSim did not include any network simulator
and also it was unable to create traces for any network simulator.
2.2 NHTSA (National Highway Traffic Safety Application)
NHTSA (National Highway Traffic Safety Application) [35] provided VANET estimation
and focused on a global perception of VANET performance. This platform is a computer-based
tool and accepts a text file during vehicular simulation. The NHTSA simulator was designed with
networking research in mind and was built on the top of NS-2 simulator. The simulator is
platform-independent and is capable to run on both Win32 as well as Linux. It has strong GUI
support implemented by C++. The main purpose of NHTSA project was to promote DSRC
standardization, and during the test-bed, a GPS receiver, Windows-based notebook and IEEE
802.11a wireless device were used as a hardware module for DSRC standard. The platform is
very scalable and flexible for researchers to alter the configuration according to the requirements.
9
2.3 FleetNet Network Demonstrator
This project was aimed to provide a platform based on simulation results from simulation
tools and a software prototype called FleetNet Demonstrator FND [34, 41]. The development of
this software was aimed to state the problems found in inter-vehicular communication and
realistic evaluation of VANET. The focus of this project was primarily on how mobility is
achieved with position based routing protocols. The demonstrator of the project performed an
outdoor experiment with six vehicles. Each vehicle had two laptops, one as a Linux system for
the communication between the vehicles and vehicular to infrastructure through WIFI card. The
other laptop had a Windows system to provide a GUI for vehicular communication as well as
communication with the GPS receiver. The demonstrator concluded some results by inspecting
the vehicular behaviour on highways and in the city, the transmission of data, velocity and
distances amongst vehicles.
2.4 CARLINK The CARLINK
project was developed to provide a wireless traffic service platform between the cars.
Vehicles were equipped with wireless transceivers to communicate with road-side infrastructure.
In addition, vehicles were also able to form ad-hoc network with each other. The base station was
able to collect car real-time data such as local weather, traffic density and all information about
current traffic and pass them to central unit for database updating, which is then sent back to the
vehicles driving past the base-station. The CARLINK project developed applications like FSF
(Finding and Sharing Files) and PB (Adhoc puzzle bubble) [38] on the java based application
called JANE. The purposes of the applications were to facilitate researchers to apply their tests
in simulated environment before being installed into the real ad-hoc network. Both these
applications could be installed into the laptops or PDA.
2.5 Car2Car The Car2Car
communication group is an organization instigated by European vehicle manufacturers

that is open for providers, research associations and other partners. Car2Car uses IEEE 802.11
WLAN technology for the vehicles to correspond with each other within the range of hundred
meters and forms an ad hoc network. The routing algorithm verifies the location and speed of a
vehicle and is able to oppose changing in the topology if any. Car2Car communication is based
10
on the following points. • Advance Driver Assistance. Design and development of active safety
applications
• Decentralized Floating Car Data
• User Communication and Information Services
2.6 Clarion The Clarion
Corporation of America, headquartered in Cypress, California, is a subsidiary of Tokyo-

based Clarion Co. Ltd., which joined the Hitachi-group as a united subsidiary since 2006. This
communication method for Intelligent Multimode Transit System (IMTS) utilizes a spread
spectrum for the automatic control of multiple vehicles. Information such as the speed and
position of the vehicles is transmitted by the transceivers installed on each vehicle. Clarion is a
low cost budget solution. At present this technology is set up in the amusement park in
Awajishima to control the shuttle bus service within the park.
2.7 IP PReVENT
PReVENT is a EU sponsored project intended to demonstrate safety application using

sensors, maps and communication systems. PReVENT will contain 23 cars, trucks and different
types of simulators for active safety including,
• Safe speed and safe following
• Collision Migration
• Intersection safety
• Lateral Support In addition to this, the following results will be displayed:
• Development of ADAS (Advance driver assistance system)
• Using maps for improved ADAS
• Evaluation of ADAS
• Sensor data fusion
11
2.8 Cooperative Vehicles and Infrastructure Systems (CVIS)
CVIS is a project with the purpose to increase road safety and effectiveness and reduce
the environmental impact of road safety. CVIS tests technologies to permit vehicles to
communicate with each other and near by road side. The project has started in 2006 and will end
till 2010. CVIS controls traffic control systems and to reach the destination with different routes.
The main purpose of this project is [16]:
• Development of standards for the vehicle-to-vehicle and vehicle-to-vehicle infrastructure

communication.
• Bringing more precision in the vehicle location and generation of more dynamic and accurate
local maps using satellite navigation and other modern methods of location referencing.
• New systems for cooperative traffic and network monitoring in both vehicle and roadside
infrastructure and to detect incidents immediately.
• Range of cooperative applications for traffic management, mobility services and driver
assistance.
• Development of toolkits to address key deployment. Local floating Car data application: The
service updates the service centre about different parameters of vehicles.
2.9 Demo 2000
Tsukuba and Japan have joined together for the demonstration of the cooperative driver
assistance system DEMO 2000 [11]. They aim to evaluate feasibility and technologies for inter
vehicle communication and are linked together to communicate with each other. DOLPHIN
(Dedicated Omni Purposed Inter-vehicle linkage) protocol was used in 5.8 GHz DCRC and
CSMA was used to access medium. Each vehicle was equipped with laser radar for the
measurement of distance, obstacles, and LCD for displaying vehicle communication.
2.10 Car Talk 2000
This is a European project to help driver based on communication between vehicles. The
communication basis in this project is self ad-hoc radio network with the purpose of developing
12
future technology. Car talk 2000 [10], [17] is a 3 year project within the IST cluster of the 5th
framework program of European commission. Car talk 2000 provides reliable components for
Advance driver Assistance (ADAS) such as Advance cruise control (ACC). With the different
approaches, the communication can greatly improve and provide better safety and fewer injuries
that are caused by collisions. The objectives of car talk 2000 are safety and to evaluate the advance
driver assistance. The Fleet net a German Project will cover the additional complements of the
project. The driver assistance system might be seen as a different perspective, research path and
methodologies but successful research has been presented by CHAUFFEUR and PATH. In order
to attain promising car driver assistance car talk 2000 creates application in the following way:
• Information and warning function.
• Communication based longitudinal control system.
• Co-operative assistance system. Information and warning function: All the parameters are
informed by the mean of information signal. These parameters include traffic load, conditions,
road accidents etc. This prior information allows a driver a pre-sense capability about safety
measures. Communication-based longitudinal control system: The ACC systems were only
capable of capturing about the vehicle in the front but it is now possible to know about any
vehicle in front that is braking. This leads to more favourable behaviour and the avoidance of
any collision that is due to the vehicle in the front. Because of more safety all these must be given
more accurate. Car Talk 2000 is now searching for more future technologies. In a denser
environment, these signals will reach through multi-hop strategy. Co-operative Assistance
System: As nowadays, misunderstanding between the drivers on merging points occurs. It will
help us in merging points. The speed and lane of the entire vehicle must be known in advance for
better communication.
13
Table 2.1 Summary of Driver Behavior Detection Methodologies
Driver Body
Author Techniques` Devices Detection Vehicle Environment
used Part Measurements Factor
On-board
system for Multi
Artaud P detecting Sensor Face - Real Time
lapses
Conditional Head
Schmidt Automated Camera Movement, - Real Time
Driving Eye
Entropy and
Chi Complexity EEG Brain, Heart - Real Time
Zhang Method beat
Real Time
Robust Non-
Qiany Ji intrusive eye Camera Face, Eye - Real Time

tracking
mechanism
Non-intrusive
Luis M prototype Camera, IR Face Position,
Bergasa computer Illuminator Eye - Real Time
vision system
Traffic flow
Dan Yu characteristic Lane, - Vehicle Simulation
method Vehicle Density
Vehicle
sensing
Jin yunk platform Vehicle
Smartphone - Simulation
Hong using Movement
smartphone
Multi model
approach to
Nanxiang track the Camera Face - Real Time

destruction
level of driver 14
CHAPTER 3
EXISTING SYSTEM
3.1 INTRODUCTION
Several routing schemes are suggested to eliminate these issues. Nearly all of the schemes
are based on blind decision based. Whenever the vehicle reaches the intersection area it will select
the shortest path between source and destination,
for example GSR , GPSR , GYTAR , GPCR , A-STAR are previous approach algorithms.
However these techniques are aimed to reduce the overall Parking Delay, they will cause the
higher traffic of packets it leads to maximum Parking Delay.
In empirical path loss models were developed in four different vehicle-to-vehicle environments, i.e.,
highway, rural, urban and suburban. In analysis of one-dimensional, an analytical model was
proposed to investigate the connectivity of VANETs in the presence of Rayleigh, Rician and
Weibull channels, from a queuing theoretic perspective. In one-hop broadcasting, analytical models
were developed for broadcast efficiency and reliability in 802.11p for Rayleigh fading channels.
In evaluation information propagation, the connectivity of information propagation was studied,

focusing on packet loss rate, packet transmission distance and effective coverage range of road-side
stations.In the case of Parking Delay-sensitive applications, the exchange of information must be
carried out very quickly in order to ensure the quality of infotainment services.Some essential
information is expected to be enqueued before reaching the destination or is lost in the event of
excessive packet Parking Delay.
An efficient forwarding node selection scheme is presented to quickly select a remote neighboring
node by utilizing cluster selection mechanisms, which greatly lowers emergency message
transmission delay and reduces message redundancy.
Based on the forwarding node selection scheme, three broadcast strategies such as bi-directional
broadcast, multidirectional broadcast, and directional broadcast are then designed to quickly select
a single forwarding node in each road direction to disseminate emergency messages.
15
3.2 Dedicated Short Range Communication
DSRC technology can be used in either a vehicle-to-vehicle (V2V) or vehicle-to-

infrastructure (V2I) format, and communicates using transponders known as on-board units (OBUs)
or roadside units (RSUs). In V2V, DSRC is used to allow vehicles to communicate with each other
through OBUs. This communication is usually for safety reasons, such as to alert the driver of one
car that the car in front of it is about to slow down. In V2I, an OBU in or on the vehicle
communicates with surrounding infrastructure equipped with an RSU. This can also alert the driver
to safety risks, such as that they are approaching a curve too quickly, or can be used to collect tolls
and parking payments.
In 1999, the United States Federal Communications Commission (FCC) allocated the 5,725 MHz
to 5,875 MHz band of radio frequency for DSRC communication. The ITS Joint Program Office of
the US Department of Transportation conducts research on DSRC and other wireless
communication technologies and their uses in vehicle safety.
Dedicated short-range communication (DSRC) is a wireless communication technology designed

to allow automobiles in the intelligent transportation system (ITS) to communicate with other
automobiles or infrastructure technology. DSRC technology operates on the 5.9 GHz band of the
radio frequency spectrum and is effective over short to medium distances.
DSRC has low latency and high reliability, is secure, and supports interoperability. It receives very
little interference, even in extreme weather conditions, because of the short range that it spans. This
makes it ideal for communication to and from fast-moving vehicles.
16
Fig 3,1 Dedicated Short Range Communication model
3.3 DISADVANTAGES
• Not always true in mobile vehicular environments
• Unable to provide complete evaluation
• Delayed Ambulance emergency message may cause a terrible traffic accident
• Uncontrolled rebroadcast mechanism usually leads to the broadcast storm problem.
3.4 PROBLEM FORMATION
The most of the VANET networks are using following communication types as a medium
for the communication, first one is vehicle to vehicle and second one belongs to vehicle to
Infrastructure. However these two types of communications are used for improvising the safety
parameters of the road segments with the help of the guiding vehicle driver to avoid the unwanted
or dangerous events, this will leads to the comfortable journey for the whole passengers.
17
Example for this communications are the traffic related information’s are obtained by the real-
time roadside units to alternate the traveling path of the user in case of the over congestion rate.
To perform this operation the information related to travelling speed and destination points are
obtained the roadside segments to maintain the traffic light effectively.
Although these types of roadside segments inflexible implementation requirements in terms of

delivery ratio and Parking Delay co efficient. Implementing this road side unit in urban area was
much complicated due to the vehicle density fluctuation between day and night time. Also road
side units are unable to obtain the information from the vehicles due to its uneven distribution it
leads to irregular connectivity. In additional the obstacle presence also stops the communication
signal propagation between Vehicles to vehicle communication.
Several routing schemes are suggested to eliminate these issues. Nearly all of the schemes are
based on blind decision based. Whenever the vehicle reaches the intersection area it will select
the shortest path between source and destination, for example GSR , GPSR , GYTAR , GPCR
, A-STAR are previous approach algorithms. However these techniques are aimed to reduce the
overall Parking Delay, they will cause the higher traffic of packets it leads to maximum Parking
Delay. To overcome this issue we propose a novel scheme based on distributed routing protocol
that will reduce the overall Parking Delay for the whole routing path before starting of the packet
communication. In this approach, our algorithm implements the power and Parking Delay
effective spine nodes on intersection of roadsides and connects all the spine nodes with help of
bridge nodes. These type of nodes helps to balance the higher no of nodes with effective Parking
Delay and connectivity co efficient. To transfer the data Packets routes which having lesser no of
weights are elected to transfer the packet.
18
CHAPTER 4
PROPOSED SYSTEM
4.1 Introduction
Ad-hoc networks are usually demanded for vehicle to vehicle (V2V) communication with
highly dynamic topologies and a stringent delay requirement.A priority based transmission scheme
is considered to guarantee the transmission of the emergency message. Priorities were considered
according to broadcasting messagesEnd-to-end packet latency increases with the increasing number
of vehicles associated with that path in vehicle network systems. In the case of Parking Delay-
sensitive applications, the exchange of information must be carried out very quickly in order to
ensure the quality of infotainment services.
Some essential information is expected to be enqueued before reaching the destination or is lost in
the event of excessive packet Parking Delay. The modified method of priority queuing is to solve
the constraints imposed by a Parking Delay in processing. By choosing a set of alternative paths
based on individual node buffer status, the proposed system dramatically minimises average
latency.
Finally, in order to the performance improvement of the proposed algorithm relative to existing
relaying schemes, both analytical and simulation results are given.
In this approach, our algorithm implements the power and Parking Delay effective spine nodes on
intersection of roadsides and connects all the spine nodes with help of bridge nodes. These type of
nodes helps to balance the higher no of nodes with effective Parking Delay and connectivity co
efficient.
To transfer the data Packets routes which having lesser no of weights are elected to transfer the
packet. In additional we are applying the Adaptive path rerouting scheme on urban vehicular adhoc
network to eliminate the traffic on road segments. When vehicle enters the roadside it should
automatically transfer packet which contains the Destination, speed, ID of the current vehicle.
Then the spine node will maintain the Real-time enhanced database of all vehicles currently
travelling on road segments. This Spine Nodes will control the traffic signals based on the collected
19
information from the vehicle.It will compute the traffic coefficient by the speed and destination of
current vehicles then it will intelligently reroute some vehicles with the help of traffic signals. For
simulation of this implementation we are using SUMO tool and getting parameter results we are
using ns2 simulation tool.
4.2 Priority based Transmission
Priority Level of Packets. In an IWSN, multiple applications would simultaneously operate

such as periodic data gathering and remote control. In addition, networking functions such as
routing and time synchronization are also running. Among them, remote control is the most crucial
and must be given the highest priority to guarantee real time communication. Furthermore, its
responses from nodes to a root node should have the higher priority than those packets belonging
to periodic data gathering. Although frequent loss of control packets affects stability and reliability
of a WSN, a best-effort service is enough. We evaluate the lower bound of available bandwidth for
lower priority packets in Section 6. Details of prioritization will be given in the next subsection.
Multiple Communication Channels. TDMA-based MAC protocols for IWSNs have channel
hopping functions to enable coexistence of multiple networks in the same area and dynamic
bandwidth allocation. In this paper, we assume that three channels are available to use.
Fig:4.1 priority base communication model
20
4.3 ADVANTAGES
• Overcoming the hidden terminal problem by using the admission control with network
encoding scheme
• Network encoding largely used to reduce the overall delay of the system.
• Admission control scheme applied to give the priority over the emergency packet to better
results.
• It can provide complete evaluation
• Increasing the throughput
• Reduce the Parking
Architecture
21
CHAPTER 4
MODULES
5.1 MODULES SPECIFICATION
In general, modules specification are usw to deal with the steps that performer developing
the system.
5.2 MODULES
Modules1: Implementation of the Network
Module2: cluster initialization
Modules3: cluster head selection
Module4: Algorithm implementation
5.3 MODULES DESCRIPTION
5.3.1 Implementation of the Network
In this module we have to apply the overall network encoding scheme in which we have
to combine all the packets available in the transmission buffer for the purpose of reduction in the
overall delay while processing the data.
These packets are decoded using the receiver side and the overall complexity of the system was
reduced.
5.3.2 TRUST MODEL MECHANISM:
In this section, we articulate an adaptive TRUST MODEL mechanism based on

quantitative risk estimation and risk tolerance. Instead of applying simple binary isolation
of malicious nodes, our approach adopts an isolation mechanism in a temporal manner
based on the risk value. We perform risk assessment with the extended D-S evidence theory
introduced in Section 3 for both attacks and corresponding countermeasures to make more
22
accurate response decisions illustrated Evidence collection. In this step, Intrusion Detection
System (IDS) gives an attack alert with a confidence value, and then Routing Table Change
Detector (RTCD) runs to figure out how many changes on routing table are caused by the
attack. Our risk aware response mechanism is divided into the following four steps Risk
assessment. Alert confidence from IDS and the routing table changing information would
be further considered as independent evidences for risk calculation and combined with the
extended D-S theory. Risk of countermeasures is calculated as well during a risk assessment
phase. Based on the risk of attacks and the risk of countermeasures, the entire risk of an
attack could be figured out. Decision making. The adaptive decision module provides a
flexible response decision-making mechanism, which takes risk estimation and risk
tolerance into account. To adjust temporary isolation level, a user can set different
thresholds to fulfill her goal.
5.3.2.1 Response to Routing Attacks:
In our approach, we use two different responses to deal with different attack methods:
routing table recovery and node isolation. Routing table recovery includes local routing table
recovery and global routing recovery. Local routing
recovery is performed by victim nodes that detect the attack and automatically recover its own
routing table. Global routing recovery involves with sending recovered routing messages by
victim nodes and updating their routing table based on corrected routing information in real time
by other nodes in VANET. Routing table recovery is an indispensable response and should serve
as the first response method after successful detection of attacks. In proactive routing protocols
like AODV, routing table recovery does not bring any additional overhead since it periodically
goes with routing control
messages. Also, as long as the detection of attack is positive, this response causes no negative
impacts on existing routing operations. Node isolation may be the most intuitive way to prevent
further attacks from being launched by malicious nodes in VANET. To perform a node isolation
response,
the neighbors of the malicious node ignore the malicious node by neither forwarding packets
through it nor accepting any packets from it. On the other hand, a binary node isolation response
23
may result in negative impacts to the routing operations, even bringing more routing damages
than the attack itself.
5.3.2.2 Risk Assessment:
Since the attack response actions may cause more damages than attacks, the risks of both
attack and response should be estimated. We classify the security states of VANET into two
categories: {Secure, Insecure}. In other words, the frame of discernment would be
{_, {Secure}, {Insecure}, {Secure, Insecure}}. Note that {Secure, Insecure} means the security
state of VANET could be either secure or insecure, which describes the uncertainty of the security
state. BelfInsecureg is used to represent the risk of VANET. Our evidence selection approach
considers subjective evidence from experts’ knowledge and objective evidence from routing table
modification. We propose a unified analysis approach for evaluating the risks of both attack and
countermeasure.
5.3.3 Cluster Initialization and Cluster Head Selection
In cluster initialization we have to divide all the Mobile Nodes depends upon the location
and we have to elect initial cluster head based on the residual energy.
Every cluster having group of Mobile Nodes as well as every Mobile Nodes having the cluster
head for the purpose communication with the sink node .
Cluster head will be the intermediate for the communication.
5.3.3.1 Connection-oriented Packet Switching (Virtual Circuit):
Before starting the transmission, it establishes a logical path or virtual connection using a
signaling protocol, between sender and receiver and all packets belongs to this flow will follow
this predefined route. Virtual Circuit ID is provided by switches/routers to uniquely identify this
virtual connection. Data is divided into small units and all these small units are appended with
help of sequence numbers. Packets arrive in order at the destination. Overall, three phases take
place here- The setup, data transfer and tear-down phases.
24
5.3.3.2 Wireless Access for Vehicular Environments (WAVE)
Wireless Access for Vehicular Environments (WAVE) is a standardized protocol stack

suite intended for use in vehicular environments.
Broadcasting of data and control packets is expected to be crucial in this environment. Both
safety-related and non-safety applications rely on broadcasting for the exchange of data or status
and advertisement messages.
Fig:5.1 WAVE communication model
5.5.4 Network Encoding Implementation
In this module we have to apply the overall network encoding scheme in which we have
to combine all the packets available in the transmission buffer for the purpose of reduction in the
overall delay while processing the data.
These packets are decoded using the receiver side and the overall complexity of the system was
reduced.
25
CHAPTER 6
SYSTEM REQUIREMENT
6.1 Introduction
Once the system has been designed, the next step is to convert the designed one in to
actual code, so as to satisfy the user requirements as excepted. If the system is approved to be
error free it can be implemented.
When the initial design was done for the system, the department was consulted for acceptance
of the design so that further proceedings of the system development can be carried on. After the
development of the system, a demonstration was given to them about working of the system. The
aim of the system illustration was to identify any malfunctioning of the system.
Implementation includes proper training to end-users. The implemented software should be
maintained for prolonged running of the software.
Initially the system was run parallel with manual system. The system has been tested with data
and has proved to be error-free and user-friendly. Training was given to end -user about the software
and its features.
6.1.1 Software Specification
Operating System : Windows XP
Tools : ns-allinone-2.28
Pre-Request Software : Cygwin
Languages : Tcl/Tk, OTcl, C++
26
6.1.2 Hardware Specification
Processor : 1.4 GHz Pentium IV Processor
RAM : 128 MB
Hard Drive : 10GB
Monitor : 14” VGA COLOR MONITOR
Keyboard : 104 Keys
Mouse : Logitech Serial Mouse
27
CHAPTER 7
SYSTEM DESIGN
7.1 Introduction to Network Simulator:
Network Simulator (NS) is a simulation tool targeted at both wired and wireless (local
and satellite) networking research. NS is a very promising tool and is being used by universities
and researchers. In this report we provided information how to install NS2 on UNIX and
Windows. Then we discussed how to use NS2 to simulate wired and wireless networks. A simple
but limited method is to combine the existing components with OTcl scripts; a complex but
powerful method is to implement new components into NS2 using C++. We discussed both of
the two methods. Finally, the methods to animate (using NAM) and to analyze (using
Xgraph/GNUplot) the simulation results are presented.
Network Simulator (NS), a discrete event simulator targeted at networking research is

widely used in universities and companies by researchers. NS provides substantial support for
simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite)
networks. The latest version of NS is 2.26 (NS2). It implements network protocols such as FTP
and Telnet, routing algorithms such as SPF and DV, and 'lower' layers such as logic link (LL) and
media access control (MAC). NS began as a variant of the REAL network simulator in 1989. In
1995 NS development was supported by DARPA through the VINT project at LBL, Xerox PARC,
UCB, and USC/ISI. Currently NS development is support through DARPA with SAMAN and
through NSF with CONSER. NS has always included substantial contributions from other
researchers, including ACIRI, UCB, CMU, and Sun Microsystems.
Nam began at LBL. The Nam development effort was an ongoing collaboration with the
VINT project. Currently, it is being developed at ISI as part of the SAMAN and Conser projects.
The simple way NS2 can be used is for studying the property of a well-known protocol.
In this case, a script language OTcl is used to glue the network components (nodes, links, agents,
applications, etc) provided by NS2, configure the parameters (band-width, Parking Delay, routing
protocol, etc) and launch activities (data transfer, topology change, etc). NS2 will read these
configurations; simulate each network event, and record events and statistics in to trace files.
28
After the simulation, Nam can demonstrate the events in a visualized way. For the simple usage
of NS2, an understanding to the simulation framework is necessary.
When NS2 is used to simulate a new protocol, e.g., an ad hoc wireless routing protocol,
the simple way is not enough. The advanced way is to hack the source of NS2 with C++, define
new network components, rebuild the whole system and run the customized version of NS2. For
the advanced usage of NS2, knowledge of the simulator implementation is required.
7.2NS2 Installation:
Windows
Installing NS2 under Windows (9x/ME/NT/2000/XP) requires additional software such as

Cygwin and XFree86 and more experience. Cygwin and XFree86 can be downloaded (free of
cost) from Internet. The all-in-one NS2 source package can be downloaded from Internet and
unpacked.
Here are the steps to build NS2 in Windows:
• Make sure system has enough memory spaces

• Install Cygwin-1.3.12 or higher with UNIX text type
• Install XFree86 binaries, sources, and configuration files
• Make sure make, patch, tar, gzip, etc works fine
• Download the all-in-one source package from the NS2 downloadpage:
http://wvw.isi.edu/nsnam/ns/ns-build.html#allinone
• Unpack the source package:gzip -d -c ns-allinone-2.x.tar.gz | tar xvf –mv nam-1.9.configure
ns-allinone-2.26/nam-1.9/configure
• install: cd ns-allinone-2.26; ./install
• Set PATH environment variable
• Validate: cd ns-2.26; ./validate
The install program will run quite a well. When finished, all is done. The binary files including
ns (for NS2) and nam (for NAM) will be created in corresponding directory, and you can run a
sample simulation via: ns tcl/ex/simple.tcl.
29
The Elements of ns-2 are listed below:
• Create the event scheduler
• [Turn on tracing]
• Create network
• Setup routing
• Insert errors
• Create transport connection
• Create traffic
• Transmit application-level data
7.3 Simulation Framework
NS2 simulation is about the processing of packets. Packets are transported among network
nodes via network links. These packets are generated by network applications (data packet) or
network protocols (control packet). An event scheduler is in charge of ordering all the packets (or
events) by their arriving time and let nodes, links and agents to handle these packets in sequence.
A full trace of each packet or their statistics information can be stored in a trace file, and used to
generate graphs or animations. In this section, the concept of node, link, agent, and scheduler will
be introduced, as well as their usage in an OTcl script to configure a specific NS2 simulation.
The following script segment creates two nodes. When a node is created, it is automatically
assigned an address and a default routing module. Nodes are the sources and destinations of the
packets. In the script, $ns is the scheduler object and node is its method to create a node, $n0 and
$nl hold the reference to the newly created node object.
Set n0 [$ns node]
Set ni [$ns node]
30
The following script segment creates one link to connect these two nodes with lM bandwidth
and l0ms Parking Delay. A link receives packets from one end, compute the Parking Delay and
transmission time, and send them to the other end after the time elapsed. If two or more packets
are going through the same link, the later packet should wait in a queue until all previous packets
are sent. If the number of packets waiting exceeds the queue limit, new packets sent to this link
are dropped.
$ns duplex-link $n0 $n1 1Mb 10ms DropTail
The default routing algorithm is centralized link state algorithm (like Dijkstra's SPF). The
route from one node to each other node is computed by the simulator and stored in the routing
table of this node. From user's point of view, each node just 'know' how to reach another node in
the network.
7.3.1 Agents: Network Protocol and Application
When the network topology is created, agents can be attached to nodes to generate packets
and put them onto the network. There are agents in different network protocol layers. In the
transportation layer, there are TCP and UDP agents. The following OTcl script segment create a
UDP agent and put it on node $n0. When an agent is attached to a node, it send and receive packet
through this node.
set udp0 [new Agent/UDP]
$ns attach-agent $n0 $udp0
In the application layer, there are agents for well known protocols like FTP, Telnet, HTTP, etc;
there are also special agents for simulation use, like CBR, which generate continues data streams.
The following OTcl script-segment creates a CBR agent and attaches it to the UDP agent. When
an agent is attached to another agent, it sends and receives data through this agent.
set cbr0 [new Application/Traffic/CBR]
$cbr0 attach-agent $udp0
31
Agents are usually created in pairs, put in different nodes and exchange data between each other.
The following OTcl script segment creates a Null agent on node $n1 and connect it to the UDP
agent on node $n0. After the agents are connected, the data generated by the CBR agent and
passed to the UDP agent will go though node $n0, the link between node $n0 and $n1, node $n1,
and received by the Null agent. The Null agent is like a null device, it discards any packet it
receives.
set null0 [new Agent/Null]
$ns attach-agent $n1 $null0
$ns connect $udp0 $null0
There are also agents in other layers, e.g., the router agents when dynamic routing is used.
However, these agents are always hidden in the inner structure of nodes, and created
automatically by the simulator.
7.3.2 Scheduler: Packet Is Event
If nodes and links is the scene in the stage, agents are the actors; then the scheduler is the
director. The scene and actors don't know how to perform unless the director tells them. The
scheduler is a build-in object in NS2 user can tell it when to do what. The following OTcl script
segment asks the scheduler to open the traffic generator at 0.5 second of the simulation and close
it at 4.5 second. The script segment also told the scheduler the whole simulation will last for 5.0
seconds.
$ns at 0.5 "$cbr0 start" $ns at 4.5 "$cbr0 stop"
$ns at 5.0 "finish"
Actually, a scheduler's work is much more than that. Every time a packet is received by an agent
or a link, a Parking Delay time representing the processing time or network Parking Delay is
computed and actually the packet is handed to the scheduler as an event. The scheduler orders all
the events by time and fires them one by one; i.e., when the time comes, the agent or link will
send the early received packet to its destination. There are also other events than packets, e.g., a
TOP agent may set a timer for its time window and re-send a packet when timeout.
32
$ns run
The above OTcl script segment will start the simulation; i.e., the scheduler begins to fire the
events one by one, according to their time stamps. In NS2, the scheduler is non-real-time by
default. The time stamps are not physical time in the simulation, but used to order the events. So
a 5.0-second simulation may take 2.0 seconds or 1 hour, de-pending on the complexity of the
topology and the number of events fired during the simulation.
7.4 Starting ns2
You start ns with the command 'ns <tclscript>' (assuming that you are in the directory
with the ns executable, or that your path points to that directory), where '<tclscript>' is the name
of a Tcl script file which defines the simulation scenario (i.e. the topology and the events). You
could also just start ns without any arguments and enter the Tcl commands in the Tcl shell, but
that is definitely less comfortable.
Everything else depends on the Tcl script. The script might create some output on stdout,
it might write a trace file or it might start nam to visualize the simulation. Or all of the above.
These possibilities will all be discussed in later sections.
7.4.1Starting nam
You can either start nam with the command 'nam <nam-file>' where '<nam-file>' is the
name of a nam trace file that was generated by ns, or you can execute it directly out of the Tcl
simulation script for the simulation which you want to visualize. For additional parameters to
nam, see the nam manual page. Below you can see a screenshot of a nam window where the most
important functions are being explained.
33
34
CHAPTER 8
SAMPLE CODING
PROPOSED CODE
#===================================
# Simulation parameters setup
#===================================
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 30 ;# number of mobilenodes
set val(rp) DSDV ;# routing protocol
set val(x) 1217 ;# X dimension of topography
set val(y) 500 ;# Y dimension of topography
set val(stop) 20.0 ;# time of simulation end
#===================================
35
# Initialization
#===================================
#Create a ns simulator
set ns [new Simulator]
#Setup topography object
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
#Open the NS trace file
set tracefile [open out.tr w]
$ns trace-all $tracefile
set route1 [open routetable.tr w]
$ns trace-all $route1
set rt [open Routingtable.tr w]
$ns trace-all $rt
set dis [open distance.tr w]
$ns trace-all $dis
set route3 [open routetable2.tr w]
36
$ns trace-all $route1
set rt1 [open Routingtable2.tr w]
$ns trace-all $rt
set f1 [open packet_receivedrss.tr w]
set f3 [open lossrss.tr w]
set f2 [open dlyrss.tr w]
set f4 [open throughputrss.tr w]
set f5 [open packet_received.tr w]
set f7 [open loss.tr w]
set f6 [open dly.tr w]
set f8 [open throughput.tr w]
#Open the NAM trace file
set namfile [open out.nam w]
$ns namtrace-all $namfile
$ns namtrace-all-wireless $namfile $val(x) $val(y)
set chan [new $val(chan)];#Create wireless channel
#===================================
# Mobile node parameter setup
37
#===================================
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channel $chan \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON
#===================================
# Nodes Definition
#===================================
#Create 30 nodes
set n(0) [$ns node]
$n(0) set X_ 205
38
$n(0) set Y_ 203
$n(0) set Z_ 0.0
$ns initial_node_pos $n(0) 20
set n(1) [$ns node]
$n(1) set X_ 254
$n(1) set Y_ 352
$n(1) set Z_ 0.0
set n(2) [$ns node]
$n(2) set X_ 507
$n(2) set Y_ 230
$n(2) set Z_ 0.0
set n(3) [$ns node]
$n(3) set X_ 320
$n(3) set Y_ 156
$n(3) set Z_ 0.0
set n(4) [$ns node]
$n(4) set X_ 357
$n(4) set Y_ 305
39
$n(4) set Z_ 0.0
set n(5) [$ns node]
$n(5) set X_ 399
$n(5) set Y_ 456
$n(5) set Z_ 0.0
set n(6) [$ns node]
$n(6) set X_ 294
$n(6) set Y_ 473
$n(6) set Z_ 0.0
set n(7) [$ns node]
$n(7) set X_ 467
$n(7) set Y_ 513
$n(7) set Z_ 0.0
set n(8) [$ns node]
$n(8) set X_ 528
$n(8) set Y_ 360
$n(8) set Z_ 0.0
40
set n(9) [$ns node]
$n(9) set X_ 645
$n(9) set Y_ 301
$n(9) set Z_ 0.0
$n(27) set Y_ 372
$n(27) set Z_ 0.0
set n(28) [$ns node]
$n(28) set X_ 700
$n(28) set Y_ 196
$n(28) set Z_ 0.0
set n(29) [$ns node]
$n(29) set X_ 919
$n(29) set Y_ 183
$n(29) set Z_ 0.0
set hrate1 1
set hrate2 2
41
source rssCalc.tcl
puts -nonewline " ENTER the SOURCE 0 to 29 : "
flush stdout
gets stdin sor
puts -nonewline " ENTER the DESTINATION 0 to 29 : "
flush stdout
gets stdin dest
#color
for {set i 0} {$i<$val(nn) } {incr i} {
$n($i) color red
$ns at 0.0 "$n($i) color brown"
for { set a1 0} { $a1<$val(nn) } { incr a1} {
set e($a1) 11
# $ns at 0.0 "$n($a1) label $e($a1)"
set energy [open energy1.tr w]
proc sensePower {} {
global array names n ns array names val array names e en1 en2 en3 energy sor
set count 0
set t [$ns now]
42
for {set i 0} {$i<$val(nn)} {incr i} {
set e($i) [expr $e($i) - 0.00475]
$ns at $t "$n($i) label $e($i)"
puts $energy "$t $e($sor)"
$ns at [expr $t+0.2] "sensePower"
proc transPower { b t} {
global ns array names n nn array names e rt re nn
set t [$ns now]
set e($b) [expr $e($b)-0.035]
$ns at $t "$n($b) label $e($b)"
$n(8) set Z_ 0.0 $ns initial_node_pos $n(8) 20 set n(9) [$ns node] $n(9) set X_ 645
$n(9) set Y_ 301
$n(9) set Z_ 0.0
$n(27) set Y_ 372
$n(27) set Z_ 0.0 $ns

initial_node_pos $n(27) 20 set
n(28) [$ns node] $n(28) set X_
700
$n(28) set Y_ 196
43
$n(28) set Z_ 0.0 $ns
initial_node_pos $n(28) 20 set
n(29) [$ns node] $n(29) set X_
919
$n(29) set Y_ 183
$n(29) set Z_ 0.0
$ns initial_node_pos $n(29) 20 set hrate1 1 set hrate2 2

source rssCalc.tcl
puts -nonewline " ENTER the SOURCE 0 to 29 : " flush

stdout gets stdin sor puts -nonewline " ENTER the
DESTINATION 0 to 29 : " flush stdout gets stdin dest
#color for {set i 0} {$i<$val(nn) }
{incr i} { $n($i) color red
$ns at 0.0 "$n($i) color brown"
} for { set a1 0} { $a1<$val(nn) } { incr a1}

{ set e($a1) 11
# $ns at 0.0 "$n($a1) label $e($a1)"
set energy [open energy1.tr w] proc sensePower {} { global array names n ns

array names val array names e en1 en2 en3 energy sor
set count 0 set t
[$ns now]
set e($i) [expr $e($i) - 0.00475]
44
$ns at $t "$n($i) label $e($i)"
puts $energy "$t $e($sor)"
}
$ns at [expr $t+0.2] "sensePower"
proc transPower { b t} {
set t [$ns now]
set e($b) [expr $e($b)-0.035]
$ns at $t "$n($b) label $e($b)"
proc receivePower { ma t} {
set t [$ns now]
set e($ma) [expr $e($ma)-0.06]
45
$ns at $t "$n($ma) label $e($ma)"
set null1 [new Agent/LossMonitor] set

null3 [new Agent/LossMonitor] set
null2 [new Agent/LossMonitor]
#find route to nodes
set des 0
puts $rt "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
puts $rt "RouteFrom RouteTo Route"
puts $rt "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
for {set des 0} {$des<$val(nn)} {incr des} { for {set j

0} {$j<$val(nn)} {incr j} {
if {$des!=$j} {
set s $j
set flag 0
set RNc $s
puts "Route from $j to $des"
while {$RNc!=$des} {
foreach rn $neighborlist($RNc) {
puts "$rn"
46
if {$rn==$des} {
set flag 1
if {$flag==1} {
set RN1 $des
} else {
set x_pos1 [$n($des) set X_]

set y_pos1 [$n($des) set Y_]
set dL [list]
foreach rnod $neighborlist($RNc) {
set x_pos2 [$n($rnod) set X_]
set y_pos2 [$n($rnod) set Y_]
set x_pos [expr $x_pos1-$x_pos2]
set y_pos [expr $y_pos1-$y_pos2]
set v [expr $x_pos*$x_pos +
$y_pos*$y_pos]
set D2 [expr sqrt($v)]
lappend dL $D2
47
set disl [lsort -real $dL]
set mindis [lindex $disl 0]
if {$i!=$des} {
if {$mindis==$nd($des,$i)} {
set RN1 $i
set RNc $RN1
lappend route($j,$des) $RNc
puts "$RNc"
puts $rt "$j
$des
$route($j,$des)"
puts $route1 "$route($j,$des) $RNc j:$j des:$des"
}
48
} }
set des 0
for {set des 0} {$des<$val(nn)} {incr des} {

for {set j 0} {$j<$val(nn)} {incr j} {
if {$des!=$j} {
set s $j set
flag 0 set RNc $s
# puts "Route from $j to $des"
while {$RNc!=$des} {
foreach rn $neighborlist($RNc) {
# puts "$rn" if
{$rn==$des} {
set flag 1
if {$flag==1} {
set RN1 $des
} else {
set x_pos1 [$n($des) set X_]

set y_pos1 [$n($des) set Y_]
set dL [list]
foreach rnod $neighborlist($RNc) {

set x_pos2 [$n($rnod) set X_] set
y_pos2 [$n($rnod) set Y_]
49
set x_pos [expr $x_pos1-$x_pos2]
set y_pos [expr $y_pos1-$y_pos2]
set v [expr $x_pos*$x_pos +
$y_pos*$y_pos]
set D2 [expr sqrt($v)]
lappend dL $D2
set disl [lsort -real $dL]
set mindis [lindex $disl 1]
if {$i!=$des} {
if {$mindis==$nd($des,$i)} {
set RN1 $i
set RNc $RN1
50
lappend route2($j,$des) $RNc
puts $route3 "$route2($j,$des) $RNc j:$j des:$des"
proc attach-cbr-traffic { node sink size interval } {
global ns set source [new Agent/UDP]

$source set class_ 2 $ns attach-agent $node
$source set traffic [new
Application/Traffic/CBR] $traffic set
packetSize_ $size
$traffic set interval_ $interval
$traffic attach-agent $source
$ns connect $source $sink
return $traffic
proc link {} {
global array names n array names nd ns array names route null2 source array names c
snode array names val sor dest array names e set sn $sor set dn $dest set s $sn
51
set sink $dn set r 0
set t [$ns now]
# $ns at [$ns now] "$n($s) label source"
# $ns at [$ns now] "$n($sink) label SINK"
# $ns at [$ns now] "$n($sn) add-mark mo blue"
# $ns at [$ns now] "$n($sink) add-mark m1 green"
# $ns at $t "$ns trace-annotate \" The route from $sn to sink\""
while {$s!=$sink} { set in [lindex

$route($sn,$dn) $r] puts "in:$in"
$ns at $t "$ns trace-annotate \" $in \""
$ns attach-agent $n($in) $null2
# set cbr01 [attach-cbr-traffic $n($s) $null2 50 0.008]
# transPower $s $t
# receivePower $in $t
# $ns at $t "$cbr01 start"
# $ns at $t "$ns trace-annotate \" Data send $s to $in \""
set $e($in) 12
$ns at $t "$n($in) label $e($in)"

# $ns at [expr $t+1.0] "$cbr01 stop" set t
[expr $t+0.01]
52
set s $in incr
r puts "r:$r"
}
puts "Time:$t"
# $ns at [expr $t+0.6] "finish"
proc Transmission1 {} {
global array names n array names nd ns array names route null1 source array names c
snode array names val sor dest null2 route2 ni set sn $sor set dn $dest set s $sn
set t [$ns now]
$ns at [$ns now] "$n($s) label source"
$ns at [$ns now] "$n($sink) label SINK"
$ns at [$ns now] "$n($sn) add-mark mo blue"
$ns at [$ns now] "$n($sink) add-mark m1 green"
$ns at $t "$ns trace-annotate \" The route from $sn to sink\"" while
{$s!=$sink} { if {$r!=0} { set in [lindex $route($sn,$dn) $r]
} else { set ni [lindex
$route2($sn,$dn) $r]
set in $ni
53
if {$r!=0} {
set cbr01 [attach-cbr-traffic $n($s) $null2 50 0.008]
} else {
transPower $s $t
receivePower $in $t
$ns at $t "$cbr01 start"
$ns at $t "$ns trace-annotate \" Data send $s to $in \""
$ns at $t "$n($in) color yellow"

$ns at [expr $t+1.0] "$cbr01 stop"
set t [expr $t+1.1]
set s $in
incr r
puts "r:$r"
}
puts "Time:$t"
$ns at [expr $t+0.3] "Transmission2"
54
set sn $sor set dn $dest set s $sn set
sink $dn set ni [lindex
$route2($sn,$dn) 0] set tru [open
thrval.tr w] for {set i 1}
{$i<$val(nn)} {incr i} { if {$i==$ni}
{ set thr($i) [myRand 60 75] puts
$tru "$i $thr($i)"
} else { set thr($i) [myRand
80 95] puts $tru " $i
$thr($i)"
}
proc Transmission2 {} {
global array names n array names nd ns array names route null1 source array names c snode
array names val sor dest array names route2
set sn $sor set

dn $dest set s
$sn
set t [$ns now]
$ns at [$ns now] "$n($s) label source"
$ns at [$ns now] "$n($sink) label SINK"
$ns at [$ns now] "$n($sn) add-mark mo blue"
$ns at [$ns now] "$n($sink) add-mark m1 green"
55
$ns at $t "$ns trace-annotate \" The route from $sn to sink\"" while
{$s!=$sink} { set in [lindex $route($sn,$dn) $r]
puts "in:$in"
set ni [lindex $route2($sn,$dn) 0]

$ns at $t "$n($ni) color red"
$ns at $t "$n($ni) label worstlink"

transPower $s $t
receivePower $in $t
$ns at $t "$cbr01 start"
$ns at $t "$ns trace-annotate \" Data send $s to $in \""
$ns at $t "$n($in) color yellow"

$ns at [expr $t+1.0] "$cbr01 stop"
set t [expr $t+1.1]
set s $in incr
r puts "r:$r"
}
puts "Time:$t"
$ns at [expr $t+0.6] "finish"
56
proc record {} {
#Get An Instance Of The Simulator set

ns [Simulator instance]
global f1 f2 f3 f4 f5 f6 f7 f8 hrate1 hrate2 hrate3 hrate4 hrate5 pdrratio null1 null2 null3 dl
#Set The Time After Which The Procedure Should Be Called Again
set time 0.05
#How Many Bytes Have Been Received By The Traffic Sinks?
set bw0 [$null1 set npkts_]

set bw1 [$null2 set npkts_] set
bw2 [$null3 set npkts_]
#packets Received by each node
set totalpkts [expr $bw0+$bw1+$bw2]

set mean [expr $totalpkts/7]
set drop0 [$null1 set nlost_] set drop1 [$null2 set
nlost_] set drop2 [$null3 set nlost_] set
totalpktss [expr ($bw0+$bw1+$bw2)/1.5] set
totaldrop [expr ($drop1+$drop0+$drop2)/100] #
puts "Total packet drops : $totaldrop" set QOS
[expr $totalpkts-$totaldrop] set QOS1 [expr
$totalpktss-$totaldrop]
57
set Size 64
set pdr0 [expr $bw0/$Size*10]

set pdr1 [expr $bw1/$Size*10] set
pdr2 [expr $bw2/$Size*10]
set total [expr $pdr0+$pdr1+$pdr2+40] set

pdrratio [expr $total/7] set dly0 [expr
(($bw0+$hrate1)*8)/(2*$time*1000)] set dly1 [expr
(($bw1+$hrate2)*8)/(2*$time*1000)] set dly2 [expr
(($bw2+$hrate1)*8)/(2*$time*1000)] set
totaldelay [expr ($dly0+$dly1+$dly2)/1]
#Get The Current Time
set now [$ns now] #Save Data To

The Files puts $f1 "$now [expr
$totalpkts]" puts $f2 "$now
[expr $totaldelay]" puts $f3 "$now
[expr $drop2]" puts $f4 "$now
[expr $QOS]" puts $f5 "$now
[expr $totalpktss]" puts $f6
"$now [expr $bw0*0.3]" puts $f7
"$now [expr $totaldrop]" puts
$f8 "$now [expr $QOS1]" #Re-
Schedule The Procedure
$ns at [expr $now+$time] "record"
#===================================
58
# Termination
#===================================
#Define a 'finish' procedure

proc finish {} { global ns
tracefile namfile $ns
flush-trace close $tracefile
close $namfile exec nam
out.nam &
exit 0 } for {set i 0} {$i < $val(nn) }
{ incr i } {
$ns at $val(stop) "\$n($i) reset"
$ns at 1.0 "Transmission1"
$ns at 0.0 "sensePower"
$ns at 1.01 "link"
$ns at 0.0 "record"
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "finish"
$ns at $val(stop) "puts \"done\" ; $ns halt"
$ns run
59
MAIN.TCL
# explicitly setup our main window
wm geometry . 800x400+10+10 wm title . "VANET AI

TRAFFIC PROPOSED SYSTEM"
# setup the frame stuff
destroy .myArea set f [frame .myArea -borderwidth 5 -

background tan] pack $f -side top -expand true -fill
both
# create a menubar
destroy .menubar menu

.menubar
. config -menu .menubar
# create a pull down menu with a label
#pack .m -expand true -ipadx 600 -ipady 400
set File1 [menu .menubar.mFile1]
.menubar add cascade -label "VANET EXISTING SYSTEM " -menu .menubar.mFile1
set File2 [menu .menubar.mFile2]
.menubar add cascade -label "VANET PROPOSED SYSTEM " -menu .menubar.mFile2
set Comp [menu .menubar.mComp]
.menubar add cascade -label "Comparision Analysis" -menu .menubar.mCom
set close [menu .menubar.sFile]
60
.menubar add cascade -label Quit -menu .menubar.sFile
$File1 add command -label Run_Simulation -command {exec ns clo1.tcl &}
$File1 add command -label Simulation_Output -command {exec nam

mrcintensivenetwork.nam &}
$File2 add command -label Run_Simulation -command {exec ./ns code.tcl &}
$File2 add command -label Simulation_Output -command {exec nam out.nam &}
$Comp add command -label "Packet Data Ratio" -command {exec xgraph
clopacketdataratio.tr normal-packetdataratio.tr -x "Time in Sec" -y "Data in Mbps" bg
"white" -t PDR -fg "blue" -lw 3 &}
$Comp add command -label "AVg Delay" -command {exec xgraph clo-delay.tr
normaldelay.tr -x "Time in Sec" -y "Data in Mbps" bg "white" -t AVG Delay -fg "blue" -
lw 3 &} $Comp add command -label "Throughput" -command {exec xgraph clo-
throughput.tr normal-throughput.tr -x "Time in Sec" -y "Data in Mbps" bg "white" -t
Throughput -fg "blue" -lw 3 &}
$Comp add command -label "Energy Consumption" -command {exec xgraph clo-energy.tr
normal-energy.tr -x "Network Size" -y "Energy Consumption Unit" bg "white" -t Energy
-fg "blue" -lw 3 &}
$Comp add command -label "Avg Routepath Length" -command {exec xgraph
cloavgroutelength.tr normal-avgroutelength.tr -x "Network Size" -y "
$close add command -label Quit -command exit
61
CHAPTER 9
SYSTEM TESTING
9.1 INTRODUCTION
Software testing is an important element of Software quality assurance and represents the
ultimate review of specification, design and coding. The increasing visibility of S/W as a system
element and the costs associated with Software failure are motivating forces for well planned,
through testing.
Though the test phase is often thought of as separate and distinct from the development
effort--first develop, and then test--testing is a concurrent process that provides valuable
information for the development team.
There are at least three options for integrating Project Builder into the test phase:
Testers do not install Project Builder, use Project Builder functionality to compile and
source-control the modules to be tested and hand them off to the testers, whose process
remains unchanged.
The testers import the same project or projects that the developers use.
Create a project based on the development project but customized for the testers (for
example, it does not include support documents, specs, or source), who import it.
Testing objectives:
There are several rules that can serve as testing objectives.
They are
Testing is a process of executing a program with the intent of finding an error.
A good test case is one that has a high probability of finding an undiscovered error.
A successful test is one that uncovers an undiscovered error.
62
If testing is conducted successfully according to the objectives stated above, it will
uncover errors in the software.
9.2 Type of testing
Testing is the process of executing the program with the intent of finding errors. Testing
cannot show the absence of defects, it can only show that software errors are present. The Testing
principles used are
• Tests are traceable to customer requirements.
• 80% of errors will likely be traceable to 20 % of program modules
• Testing should begin ‘in-small’ and progress towards testing ‘in large’.
9.2.1 White Box Testing:
This test is conducted during the code generation phase itself. All the errors were rectified
at the moment of its discovery. During this testing, it is ensured that
• All independent paths within a module have been exercised at least one
• Exercise all logical decisions on their true or false side.
• Execute all loops at their boundaries.
9.2.2 Black Box Testing:
It is focused on the functional requirements of the software. It is not an alternative to

White Box Testing; rather, it is a complementary approach that is likely to uncover a different
class of errors than White Box methods. It is attempted to find errors in the following categories.
• Incorrect or missing functions
• Interface errors
• Errors in data structures or external database access
• Performance errors and

63
• Initialization errors.
It is already stated that the methodology used for program development is the
‘Component Assembly Model’. Before integrating the module-interfaces, each module-interface

is tested separately. This is called Unit Testing.
9.2.3 Alpha Testing:
A series of Acceptance tests were conducted to enable the employees of the firm to
Validate requirements. The End User conducted it. The suggestions, along with the additional
requirements of the end user were included in the project.
9.2.4 Beta Testing:
It is to be conducted by the end-user without the presence of the developer. It can be

conducted over a period of weeks or month. Since it is a long time consuming activity, its result
is out of scope of this project report. But its result will help to enhance the product at a later time.
9.2.5 Validation Testing:
This provides the final assurance that the software meets all functional, behavioral and
performance requirements. The software is completely assembled as a package. Validation
succeeds when the software functions in which the user expects.
9.2.6 Output testing:
After performing the validation testing, next step is output testing of the proposed system
since no system could be useful if it does not produces the required output generated or considered
in to two ways. One is on screen and another is printed format. The output comes as the specified
requirements by the user. Hence output testing does not result in any correction in the system.
9.2.7 User Acceptance testing:
User acceptance of a system is the factor for the success of any system. The system under
consideration is tested for the user acceptance by constantly keeping in touch with the prospective
system users at the time of developing and making changes wherever required.
64
• Input screen design
• Output screen design
• On-line message to guide the user
• Format of the ad-hoc reports and other outputs.
Taking various kinds of test data does the above testing. Preparation of test data plays a
vital role in the system testing. After preparing the test data the system under study is tested using
the test data. While testing the system by using test data errors are again uncovered and corrected
9.3Unit Testing:
This is the first level of testing. In this different modules are tested against the
specifications produced during the design of the module. During this testing the number of
arguments is compared to input parameters, matching of parameter and arguments etc. It is also
ensured whether the file attributes are correct, whether the Files are opened before using, whether
Input/output errors are handled etc. Unit Test is conducted using a Test Driver usually.
9.4 Integration Testing:
Integration testing is a systematic testing for constructing the program structure, while at
the same time conducting test to uncover errors associated within the interface. Bottom-up
integration is used for this phase. It begins construction and testing with atomic modules. This
strategy is implemented with the following steps.
• Low-level modules are combined to form clusters that perform a specific

software sub function.
• The cluster is tested.
• Drivers are removed and clusters are combined moving upward in the program
structure.
by using above testing steps and corrections are also noted for future use.
65
TEST REPORT BY SYSTEM ANALYST / PROGRAMMER
S.NO TESTING PARAMETER OBSERVATIONS
1. INTERFACE TESTING
a) Mouse / Tab Navigation OK
OK
b) User Friendlines
OK
c) Consistent menus OK
d) Consistent Graphical buttons
66
2. VALIDATION TESTING
a) Check for improper or inconsistent OK

typing
b) Check for erroneous initialization or OK

default values
OK
c) Check for incorrect variables names

OK
OK
d) Check for inconsistent data types
e) Check for relational / arithmetic

operators
67
3. DATA INTEGRITY/SECURITY
TESTING
a) Data Insert /Delete /Update

OK
b) Condition(Underflow, OK
Overflow exception)
OK
c) Check For Unauthorized
Access of data
OK
d) Check For Data Availability
4. EFFICIENCY TESTING
a) Throughput of the System OK
b) Response Time Of the OK
System
c) Online Disk Storage OK
d) Primary Memory Required OK

by the System.
68
5. ERROR HANDLING ROUTINES
a) Error Description are OK
Intelligent / Understandable
b) Error Recovery Is Smooth OK
c) All Error handling routines OK

are tested and executed at least
ones.
USER TEST REPORT (to filled by user)
S.NO TESTING PARAMETER OBSERVATIONS
1. TEST FOR PULLED DOWN MENUS
AND MOUSE OPERATIONS
a) All the relevant Pull Down

YES
Menus, Scroll Bar, Dialog

Boxes and Buttons Functioning
Properly?
69
b) Is the Appropriate menu bar
displayed in the appropriate
Context? YES
c) Are all menu functions and pull

down Sub-Functions properly
listed?
YES
d) Does each menu function

perform according to design
Specification?
e) Is it Possible to invoke each YES
menu functions using it is
alternative keys?
f) Is all data content with in the
Window Properly addressable
with mouse, Functional Keys and
YES
Keyboard?
g) Does the Window Properly
generate when it is overwritten
then Recalled?
h) Is the active Window Properly
YES
70
YES
71
Highlighted? YES
2. TEST FOR DATA ENTRY LEVEL :
a) Is alphanumeric data entry

properly echoed and input to the
system? YES
b) Do graphical modes of data

entry such as Scrollbars work
properly? YES
c) Are data input messages
intelligible?
d) Is invalid data properly
recognized? YES
f) Is all input data entry properly
Saved?
YES
YES
72
3. TEST FOR VERIFYING OUTPUTS
a) Whether Output displayed is

according to requirement and
YES
printed with proper
alignment?
b) If Calculations are there, do

you check them?
YES
c) Are Report formats according
to need?
e) Are reports can be Printed or
printer? YES
YES
73
CHAPTER 10
PERFORMANCE EVOLUATION
10.1INTRODUCTION
To uphold an effective way for using VANET solutions, there exists significant number
of challenges which includes an effective way for data dissemination especially at the threshold
levels. Considerable amount of solutions was proposed in VANET for resolving the issues.
However, a phenomenal method to address the issues is still in debate. In the related work it has
been addressed that the challenges taken up for solving the existing issues is one among the
following themes 1) Avoidance of transmission collisions by designing a new scheme for
channel access. 2) Effective method for controlling the collisions in dense regions without
compromising the performance of the network. 3) Methods for effective dissemination of data
to the vehicles.
The addressed challenges are, data dissemination and collision control. In this chapter both the
methodologies are combined together and the performance of this hybrid methodology has been
measured using appropriate performance measures. (i.e.) a single will be upholding both the
phases such as Adaptive data dissemination and fuzzy based congestion control for improving
and evaluating the performance of VANET. This chapter has been organized as follows where
section 6.2 describes the hybrid approach in brief. In section 6.3 the detailed methodology of
proposed approach has been represented in the form of diagram. In section 6.4 the performance
of the proposed approach is measured using appropriate metrics. In section 6.5, statistical tools
are indulged to show the significance of the proposed method.
10.2 HYBRID APPROACH
In objective I, an efficient Adaptive Load Balancing has been proposed for effective data
dissemination in VANET and in the second objective an effective k-means machine learning
algorithm has been proposed for congestion control.
74
In this objective a hybrid approach of ALB and Fuzzy C-means data congestion control has been
efficiently proposed and it performance has been evaluated under different VANET simulation
scenarios. The RSU’s at the junctions has been imposed with proposed Adaptive Data
Dissemination for efficient data dissemination and proposed Machine Learning based
congestion control mechanism for collision control. This Hybrid Approach has been tested with
different communication densities (Message count) and the results are interpreted with Packet
Reception Rate (PRR) and End to End (E2E) Parking Delay.
In this phase the proposed method has been evaluated and existing communication models
Nakagami and 2wayRound
10.2.1 PROPOSED HYBRID METHODOLOGY
Hybrid methodology in this phase fuses the Phase-I Adaptive Load Balancing (ALB) and
Phase-II Fuzzy based Collision Control technique in a single RSU and tests the performance of
it in terms of End-to-End Parking Delay and packet reception rate. The detailed configuration of
Hybrid Approach is given in Figure 6.1.
Figure 10.1: Hybrid Approach
In figure 6.1 it is shown that the hybrid approach is the club between ALB and Fuzzy congestion
control in which ALB composes of all the cases such as scheduled request, Ondemand request
and broadcasting of data. And from the fuzzy based congestion control the phases such as
detection of collision, data control phase and collision control phase are included. With this
hybrid approach, an RSU is fed with both the phases and the performance has been evaluated
and compared with the existing approache.
75
10.3 Experimental Setup
The proposed hybrid methodology is implemented in the same simulation scenario

which is used to evaluate the fuzzy based congestion control in the previous chapter. For the
simulation process of mobility in vehicles Simulation of Urban MObility (SUMO) [50] is used.
For the simulation of VANET, Network Simulator 2 (NS2) has been employed [51]. To
incorporate the output (mobility model) simulated by SUMO into NS2 MObility VEhicular
(MOVE) model generator [52] are used. The parameters used to evaluate the proposed
methodology have been tabulated in Table 6.1.
Table 6.1: Simulation Parameters

Parameters
Rang e
Frequency of message 10 to 25 messages Total

number of lanes
8
Total number of vehicles 10 – 100 in each

lane Speed of the vehicle 0-50 Km/h
Transmission Rate 6 Mbps
MAC Type IEEE 802.11p
Routing Protocol Nakagami
Simulation time Maximum of 1000 seconds
Total Runs 20
76
10.3.3 Performance Metrics
Two different performance metrics are used for evaluating the proposed hybrid
methodology under different simulation region such as different communication range, varied
communication density and different cluster size, varied message density, delivery ratio.
10.3.4 Packet Reception Rate (PRR)
Packer reception rate is defined as the probability of a packet to be delivered to the receiver
in a successful manner. It can be formulated as
In which 𝑁 is the total number of tagged nodes that actually receive messages from the
node that are actually tagged to it and 𝑀 denotes total number of nodes that are tagged with the
communication range.
10.3.5 End to End Parking Delay
End to End Parking Delay is defined as the total Parking Delay it takes for a message to
be received by the end user from the source the message originated.
10.4 Simulation Results
Table 6.2 shows the simulation results of the proposed hybrid approach along with
existing propagation model such as Nakagami and 2RayRound with respect to different
communication range of RSU. Figure 6.2 shows the graphical representation of PRR results
with different communication range for comparing the proposed algorithm along with the
existing approaches.
Table 10.2 Simulation Results of PRR w.r.t Different communication
range of RSU
Comm. Range Nakagami 2RayRound Hybrid

77
0.2 1 1 1
0.4 1 1 1
0.6 1 0.9 1
0.8 1 0.7 1
1 1 0.5 0.8
1.2 0 0.3 0.6
1.4 0 0.1 0.4
Nakagami 2RayRound Hybrid
1.2
0.8
0.6
0.4
0.2
0.2 0.4 0.6 0.8 1 1.2 1.4
DISTANCE OVER MAXIMUM COMMUNICATION RANGE (D/CR)
Figure 10.2 PRR w.r.t Different communication range of RSU
On observing the performance of algorithms in Table 6.2 for different communication range, the
proposed algorithm outperforms the existing approach 2RayRound with 10%, 30%, 37.5%, 50%
and 75% for communication range with 0.6, 0.8,
1.0, 1.2 and 1.4 respectively. It performs equally on communication range 0.2 and 0.4. When
compared with Nakagami the proposed algorithm performs 100% well on communications with
1.2 and 1.4. For the other communication ranges from 0.2 to 0.8 both performs equally. And for
the communication rage with 0.6 Nakagami outperforms the hybrid approach with 37%
efficiency.
78
Table 6.3 shows the simulation results of the proposed hybrid approach along with existing
algorithms such as MORS [80, 81], VDA [82], DCF [83] and ROVER [84] with respect to
different communication density of RSU. Figure 6.3 shows the graphical representation of E2E
Parking Delay results with varied communication density for comparing the proposed algorithm
along with the existing approaches.
Table 10.3 Simulation Results of E2E Parking Delay w.r.t varied communication
density
Msg. Density MORS VDA DCF ROVER HYBRID
5000 0.03 0.04 0.09 0.5 0.03
6000 0.03 0.04 0.09 0.5 0.03
7000 0.03 0.05 0.1 0.6 0.03 8000 0.05

0.05 0.1 0.6 0.03 9000 0.05 0.05 0.1
0.7 0.04
10000 0.05 0.07 0.12 0.8 0.04
79
Figure 10.3 E2E Parking Delay w.r.t varied communication density
On addressing the performance of the proposed algorithm from Table 6.3, the proposed
algorithm outperforms existing algorithm MORS with an efficiency of 40%, 20% and 20% for the
communication density values 8000, 9000 and 10000 respectively. On comparing the results with
VDA for communication density from 5000 to 10000 the proposed outperforms with 25%, 25%,
40%, 40%, 20% and 42.9% efficiency. On DCF, hybrid approach outperforms with 66.7%, 66.7%,
70%, 70%, 60%, and 66.7% efficiency for different communication density ranges from 5000 to
10000 with an interval of 1000. Over ROVER, proposed approach outperforms with 94%, 94%,
95%, 95%, 94% and 95% for communication density ranges from 5000 to 10000 with an interval
of 1000 respectively.
Table 10.4 Simulation Results of E2E Parking Delay w.r.t varied communication density and
cluster size of hybrid approach
Msg. Density k=4 k=5 k=6

5000 0.08 0.05 0.03
6000 0.07 0.05 0.03
7000 0.08 0.06 0.03
8000 0.09 0.07 0.03
9000 0.09 0.07 0.04
10000 0.09 0.08 0.04
80
k=4 k=5 k=6
0.1
500 0 600 0 700 0 800 0 900 0 10000

COMMUNICATION DENSITY
Figure 10.4: Simulation Results of E2E Parking Delay w.r.t varied communication density
and cluster size of hybrid approach
Table 6.4 shows the performance of proposed approach on varied communication density with
different cluster size. Figure 6.4 shows the graphical representation of the proposed approach with
different cluster size. On interpreting the results of Table 6.4, the proposed algorithm shows better
performance when the cluster size is six.
algorithms with respect to different message density of RSU. Figure 6.5 shows the graphical
representation of PRR results with varied message density for comparing the proposed algorithm
along with the existing approaches.
81
Table 10.5 Simulation Results of PRR w.r.t varied message density
Msg. Density VDA MORS DCF ROVER HYBRID

5000 0.8 0.9 0.75 0.4 0.93
6000 0.9 0.93 0.7 0.4 0.9
7000 0.8 0.88 0.6 0.5 0.82
8000 0.75 0.85 0.55 0.5 0.8
9000 0.65 0.75 0.55 0.6 0.76
10000 0.6 0.73 0.5 0.65 0.73
11000 0.45 0.7 0.4 0.7 0.72
12000 0.4 0.65 0.3 0.66 0.7
13000 0.3 0.6 0.2 0.6 0.7
14000 0.15 0.5 0.18 0.52 0.68
15000 0.1 0.45 0.15 0.38 0.64
Figure 10.5 PRR w.r.t varied message density
82
On addressing the performance of the proposed algorithm from Table 6.5, the proposed algorithm
outperforms existing algorithm MORS with an efficiency of 13%, 0% 2%, 6%, 14%, 17% 37&,
42%, 57%, 77% and 84% for the message density ranges from 5000 to 15000 with 1000 as interval
respectively. On comparing the results with DCF for message density from 5000 to 15000 the
proposed outperforms with 19%, 22%, 26%, 31%, 27%, 31%, 44%, 57%,71%, 73% and 76%
efficiency respectively. On ROVER, hybrid approach outperforms with 56%, 55%, 39%, 37%,
21%, 10%, 2%, 5%, 14%, 23% and 40% respectively.
Table 10.6 Simulation Results of PRR w.r.t varied message density and cluster size
of hybrid approach
Msg. Density k=4 k=5 k=6

5000 0.8 0.9 1
6000 0.8 0.9 1
7000 0.76 0.82 1
8000 0.73 0.8 1
9000 0.72 0.76 0.95
10000 0.7 0.72 0.94
11000 0.7 0.71 0.93
12000 0.68 0.7 0.9
13000 0.64 0.7 0.89
14000 0.6 0.69 0.88
15000 0.5 0.69 0.88
83
k=4 k=5 k=6
1.2
0.8
0.6
5000 6000 7000 8000 9000 10000 11000 12000 13000 14000 15000
MESSAGE DENSITY
Figure 10.6: Simulation Results of PRR w.r.t varied message density and cluster size
of hybrid approach
Table 6.6 shows the performance of proposed approach on varied message density with different
cluster size. Figure 6.6 shows the graphical representation of the proposed approach with different
cluster size. On interpreting the results of Table 6.6, the proposed algorithm shows better
performance when the cluster size is four.
algorithms with respect to different message density of RSU. Figure 6.7 shows the graphical
representation of PRR over Parking Delay ratio results with varied message density for comparing
the proposed algorithm along with the existing approaches.
PRR Over Parking Delay Ratio w.r.t. Varied Message Density
Table 10.7 Simulation Results of PRR over Parking Delay ratio w.r.t varied message density
Msg. Density VDA MORS DCF HYBRID

5000 55 55 50 65
6000 53 57 48 63
7000 50 58 42 59
8000 43 49 40 57
9000 32 44 37 53
84
10000 27 39 32 50
11000 25 38 30 48
12000 20 37 21 46
13000 16 34 16 43
14000 13 32 13 41
15000 10 30 10 40
Figure 10.7 PRR over Parking Delay ratio w.r.t varied message density
On addressing the performance of the proposed algorithm from Table 6.7, the
proposed algorithm outperforms existing algorithm VDA with an efficiency of 15%,
15% 15%, 24%, 39%, 46% 47%, 56%, 62%, 68% and 75% for the message density
ranges from 5000 to 15000 with 1000 as interval respectively. On comparing the
results with MORS for message density from 5000 to 15000 the proposed
outperforms with 15%, 9%, 1%,
14%, 16%, 22%, 20%, 19%, 20%, 21% and 25% efficiency respectively. On DCF, hybrid
85
approach outperforms with 23%, 23%, 28%, 30%, 36%, 37%, 54%, 62%, 68% and 75%
respectively.
10.5 STATISTICAL ANALYSIS
As it is discussed in Chapter 3, Statistical tools such as ANOVA and Duncan Multiple

Range Test (DMRT) are used to prove the significance of the proposed algorithm on comparing
the mean of the existing algorithms.
Table 6.8 Statistical tests on performance of PRR w.r.t Different communication

range of RSU ANOVA Based Result analysis
ANOVA
Source Factor Sum df Mean F Sig.
of Squar
Between .123 2 .061 .435 .654
PRR
w.r.t GroupsWit
hin 2.540 18 .141
Different
communicati Groups
on Total 2.663 20
86
Table 6.8 shows the ANOVA and DMRT test results for PRR with respect to different
communication range with other existing algorithms. On observing the sigma value in Table 6.8
which is greater than 0.05 represents that there is no significant difference among the algorithms.
Hence, post hoc analysis cannot be performed.
Table 6.9 Statistical tests on performance of E2E Parking Delay w.r.t varied
communication density
ANOVA Based Result analysis
DUNCAN MULTIPLE RANGE

TEST
Subset for alpha =

0.05
1 2
HYBRI 6 .033
MORS 6 .040
DCA 6 .050
VDF 6 .100
ROVER 6 .6167
Sig. .055 1.000
87
DMRT Based Result analysis
Table 6.9 shows the ANOVA and DMRT test results for E2E Parking Delay w.r.t varied
communication density with other existing algorithms. On observing the sigma value in Table
6.9(a) which is less than 0.05 represents that there exists a significant difference among the
algorithms. To find the homogenous group between the algorithms, DMRT test has been
performed as the Post-hoc analysis after ANOVA and the results are tabulated in Table 6.9 (b).
The result shows that there exist two groups are present in which the proposed HYBRID approach
and existing approaches MORS, DCF, VDA lies in the same group whereas ROVER exist in
different group.
ANOVA
Source Factor Sum Df Mean F Sig.
of Squar
Between .808 4 .202 6.028 .000

E2E Parking GroupsWithin 1.676 50 .034
Delay
w.r.t Groups Total 2.484 54
varied
88
Subset for alpha =
1 2
HYBRID 11 .721
MORS 11 .761
ROVER 11 .5373
VDA 11 .53
DCF 11 .44
Sig. .611 .264
DMRT Based Result analysis
Table 6.10 shows the ANOVA and DMRT test results of E2E Parking Delay w.r.t varied
communication density with other existing algorithms. On observing the sigma value in Table
6.10(a) which is less than 0.05 represents that there exists a significant difference among the
algorithms. To find the homogenous group between the algorithms, DMRT test has been
performed as the Post-hoc analysis after ANOVA and the results are tabulated in Table 6.10 (b)
in which the proposed HYBRID approach and existing approach MORS lies in the same group
whereas VDA, DCF and ROVER exist in different group.
89
ANOVA
Source Factor Sum Df Mean F Sig.
of Squar
Between 3250.068 3 1083.356 6.646 .001

E2E Parking GroupsWithin 6520.364 40 163.009
Delay
Groups Total 9770.432 43
w.r.t
varied
Subset for alpha =
1 2
HYBRID 11 51.36
MORS 11 43.00
VDA 11 31.27
DCF 11 30.81
Sig. .132 .934
90
CHAPTER 11
CONCLUSION
In this paper, we proposed a new analytical model for the performance analysis and clustering
design in VANETs.
• Our model integrates SCRP protocol operations, Vehicle wireless channel conditions, and the
moving pattern of the vehicles. We also derived closed-form expressions for average packet
loss probability and throughput of a VANET cluster.
• Validated by extensive simulations, our model represents a new approach for the performance
study of VANET.
• In particular, we derived system measures that quantify the effects of cluster design criteria
on VANET performance.
• Such measures can be used to determine the suitable cluster size, typical network
Connectivity, and adequate data traffic control to achieve the desired system reliability and
network throughput.
• The proposed model and analysis provided guidelines for the design and management of
VANETs to maintain acceptable communication performance.
• In particular, we derived system measures that quantify the effects of cluster design criteria
on VANET performance.
• Such measures can be used to determine the suitable cluster size, typical network
Connectivity, and adequate data traffic control to achieve the desired system reliability and
network throughput.
• The proposed model and analysis provided guidelines for the design and management of
VANETs to maintain acceptable communication performance.
91
REFERENCE
• G. Karagiannis et al., “Vehicular networking: A survey and tutorial on requirements,

architectures, challenges, standards and solutions,” IEEE Commun. Surveys Tuts., vol. 13, no.
4, pp. 584–616, 2011.
• Amendment 6: Wireless Access in Vehicular Environment (Part 11: Wireless LAN medium
access control (MAC) and physical layer (PHY) specifications), IEEE Std 802.11p TM-2010,
Jun. 17, 2010.
• H. Su and X. Zhang, “Clustering-based multichannel MAC protocols for QoS
provisionings over vehicular ad hoc networks,” IEEE Trans. Veh. Technol., vol. 56, no. 6, pp.
3309–3323, Nov. 2007.
• O. Kayis and T. Acarman, “Clustering formation for inter-vehicle communication,” in Proc.

IEEE Intell. Transp. Syst. Conf., Seattle, WA, USA, Sep. 2007, pp. 636–641.
• Z. Wang, L. Liu, M. Zhou, and N. Ansari, “A position based clustering technique for ad hoc
intervehicle communication,” IEEE Trans. Syst., Man Cybern.—Part C: Appl. Rev., vol. 38, no.
2, pp. 201–208, Mar. 2008.
• Elgarej Mouhcine; Yassine Karouani; Khalifa Mansouri; Youssfi Mohamed “Toward a

distributed strategy for emergency ambulance routing problem” 2018 4th International
Conference on Optimization and Applications (ICOA)
• Xu Wang; Jian Liu “Design and Implementation for Ambulance Route Search Based on the
Internet of Things” 2011 Third International Conference on Communications and Mobile
Computing
• Ashutosh Sharma; Rajiv Kumar “An optimal routing scheme for critical healthcare HTH
services — an IOT perspective” 2017 Fourth International Conference on Image Information
Processing (ICIIP) .
92
• Dipali B. Gaikwad; Yogesh W. Wanjari; K. V. Kale “Disaster management by integration of
web services with geospatial data mining” 2014 Annual IEEE India Conference
(INDICON)
• Amuleen Gulati; Gagangeet Singh Aujla; Neeraj Kumar; Sahil Garg; Georges Kaddoum
“Software-Defined Content Dissemination Scheme for Internet of Healthcare Vehicles in
COVID-Like Scenarios” IEEE Internet of Things Magazine ( Volume: 4, Issue: 3, September
2021)
APPENDIX
SCREEN SHOOTS OF THE PROJRCT
93

Vanet Traffic Report All Re

Uploaded by

Copyright:

Available Formats

Vanet Traffic Report All Re

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vanet Traffic Report All Re

Uploaded by

Copyright:

Available Formats

CHAPTER 1

1.2ABOUT THE DOMAIN

1.2.1 VEHICULAR AD-HOC NETWORK (VANET)

Vehicular Ad-hoc Network is a term which describes an infrastructure less network

• 6.3 million Police reported traffic accidents

• 43,000 people were killed

• Millions of people were injured

1.2.2 FEATURES OF VANET

• The nodes in a VANET are vehicles and road side units

1.2.3 VANET Simulation Problem

‘VEHICULAR ad hoc networks’ (VANETs) are self-configuring networks where the

1.3 SCOPE OF THE PROJECT

1.4 ORGANIATION OF THE CHAPTER

2.1 GrooveSim Network Simulation

2.2 NHTSA (National Highway Traffic Safety Application)

2.4 CARLINK The CARLINK

2.5 Car2Car The Car2Car

communication group is an organization instigated by European vehicle manufacturers

• Decentralized Floating Car Data

• User Communication and Information Services

2.6 Clarion The Clarion

Corporation of America, headquartered in Cypress, California, is a subsidiary of Tokyo-

PReVENT is a EU sponsored project intended to demonstrate safety application using

• Safe speed and safe following

• Lateral Support In addition to this, the following results will be displayed:

• Development of ADAS (Advance driver assistance system)

• Using maps for improved ADAS

• Sensor data fusion

• Development of standards for the vehicle-to-vehicle and vehicle-to-vehicle infrastructure

2.9 Demo 2000

2.10 Car Talk 2000

• Information and warning function.

• Communication based longitudinal control system.

Qiany Ji intrusive eye Camera Face, Eye - Real Time

Nanxiang track the Camera Face - Real Time

In evaluation information propagation, the connectivity of information propagation was studied,

DSRC technology can be used in either a vehicle-to-vehicle (V2V) or vehicle-to-

Dedicated short-range communication (DSRC) is a wireless communication technology designed

• Unable to provide complete evaluation

• Delayed Ambulance emergency message may cause a terrible traffic accident

• Uncontrolled rebroadcast mechanism usually leads to the broadcast storm problem.

3.4 PROBLEM FORMATION

Although these types of roadside segments inflexible implementation requirements in terms of

4.2 Priority based Transmission

Priority Level of Packets. In an IWSN, multiple applications would simultaneously operate

Fig:4.1 priority base communication model

• Increasing the throughput

• Reduce the Parking

5.1 MODULES SPECIFICATION

Modules1: Implementation of the Network

Module2: cluster initialization

Modules3: cluster head selection

Module4: Algorithm implementation

5.3 MODULES DESCRIPTION

5.3.1 Implementation of the Network

5.3.2 TRUST MODEL MECHANISM:

In this section, we articulate an adaptive TRUST MODEL mechanism based on

5.3.2.1 Response to Routing Attacks:

5.3.2.2 Risk Assessment:

5.3.3 Cluster Initialization and Cluster Head Selection