Universitatea Politehnica Bucuresti Facultatea de ...cipsm.hpc.pub.ro/documentation/Dragoi_Vlad.pdf · Universitatea Politehnica Bucuresti Facultatea de Automatica si Calculatoare

Universitatea Politehnica Bucuresti

Facultatea de Automatica si Calculatoare

TrafficView

Student: Scientic coordinators:

Drãgoi Vlad-Alexandru Prof. Dr. Ing. Valentin Cristea,

Sl. Ing. Dr. Ciprian Dobre

July 2010

Vlad Drãgoi TrafficView

- 2 -

Contents

Abstract......................................................................................................................3

1. Introduction............................................................................................................4

1.1. Congestion in major cities.........................................................................4

1.2. Backgroung and related work....................................................................8

2. Simulation Environment......................................................................................10

3. DSRC Protocol.....................................................................................................13

4. TrafficView Architecture......................................................................................15

5. Results and Discussions.......................................................................................23

5.1. Testing Conditions ............................................................................................23

5.2. Results Obtained ..............................................................................................27

6. Conclusions and future work...............................................................................43

7. References............................................................................................................45


- 3 -

Abstract

Time in essential for essential for each of the millions of drivers and passangers of

cars that are in traffic right now. Everyone is trying to reach his/her destination as soon as

possible, and, preferably, with the lowest cost possible. Traffic density has increased

exponentially in the last century, but the infrasctructure hasn't kept up with the growing

number of running automobiles. Thus, in every major city, and even in smaller cities, at rush

hours, traffic jam always occur. Drivers who are familiar with a city may try to avoid jams,

opting for alternative routes, witch are not the shortest path possible, but provide a better time

to destination. But these decisions are based on personal experiences, and sometimes prove to

be even worse, that is a longer time to destination, than the shortest route, witch may have

been a litter congested, but runned fairly well. It would be better if each driver knew, in real

time, each road's condition, the average speed recorded by other vehicles while passing

through each road segment, and adjut his/her route accordingly.

This thesis aims to offer a valid solution in cities with a high congestion ratio,

agregating real-time statistics, and offering best route for each vehicle witch requires one,

using wireless communication between cars and traffic lights equipped with wireless

technology.


- 4 -

1. Introduction

The technological advancement over the last ten years has been truly remarcable, and

more and more solutions are rising using such technologies. Problems often occur when the

existing infrasctructure doesn't keep up with the rest of the world and its expansion in every

field. Such problems appear ever so frequently in auto traffic.

Increasing numbers of cars overwhelm the out-of-date infrasctructure ever since the

automobile has entered mass production, and traffic jams have been a real problem since then.

1.1. Congestion in major cities

Traffic congestion occurs when a volume of traffic generates demand for space greater

than the available road capacity, this being the point commonly termed saturation.

Congestion can be reduced by either increasing road capacity (supply), or by reducing

traffic (demand). Increased supply can include:

• Adding more capacity at bottlenecks (such as by adding more lanes, or by removing

local obstacles like bridge supports and widening tunnels)

• Adding more capacity over the whole of a route (generally by adding more lanes)

• Creating new routes

• Traffic management improvements

• Public transportation encouragement

Every person that lives in a city always requires some mode of transportation to get by

and attend his/her daily matters, and this increases the number and gravity of congestion that

inevitably occur on many of the city's streets. Public trasportation in major cities are

permanently advertised by its leaders as the way to travel within the city boundaries, as it is

more environment friendly, and, as more and more people use it, the less personal vehicles are

there to induce congestions, and thus public transportation would run even better, and every

passanger would reach his/her destination even faster. This matter has been highly debated,


- 5 -

and also has many disadvantages, like public transportation safety, confort, the area that it

serves, the fact that many public transportation systems don't provide non-stop serives, etc.

Traffic management, or intelligent transportation system, include several systems that

provide traffic safety, guidance and optimization:

• Traffic reporting, via radio, GPS or possibly mobile phones, to advise road users

• Variable message signs installed along the roadway, to advise road users

• Navigation systems, possibly linked up to automatic traffic reporting

• Traffic counters permanently installed, to provide real-time traffic counts

• Automated highway systems, a future idea which could reduce the safe interval

between cars (required for braking in emergencies) and increase highway capacity

by as much as 100% while increasing travel speeds

Figure 1. Traffic jam in Los Angeles, 1953


- 6 -

Traffic congestions are always a bad thing and include a number of negative effects:

• Wasting time of motorists and passengers . As a non-productive activity for most

people, congestion reduces regional economic health.

• Delays, which may result in late arrival for employment, meetings, and education,

resulting in lost business, disciplinary action or other personal losses.

• Inability to forecast travel time accurately, leading to drivers allocating more time to

travel "just in case", and less time on productive activities.

• Wasted fuel increasing air pollution and carbon dioxide emissions owing to increased

idling, acceleration and braking.

• Wear and tear on vehicles as a result of idling in traffic and frequent acceleration and

braking, leading to more frequent repairs and replacements.

• Stressed and frustrated motorists, encouraging road rage and reduced health of

motorists

• Emergencies: blocked traffic may interfere with the passage of emergency vehicles

traveling to their destinations where they are urgently needed.

Congested main streets lead to the flooding of the smaller side streets that often also

become congested, and lead to air and noise pollution in these areas which are frequently

residential areas.


- 7 -

Figure 2. Traffic jam in Dehli

Advances in mobile computing and wireless communication have offered new

possibilities for Intelligent Transportation Systems (ITS).

By adding short-range communication capabilities to vehicles, the devices form a

mobile ad-hoc network, allowing cars and road-sided wireless equipments to exchange

information about road conditions. This is often referred to in the literature as Vehicular Ad-

hoc Networks (VANETs) or Inter-Vehicular Communication (IVC) systems.

The users of a VANET, drivers or passengers, can be provided with useful information

and with a wide range of interesting services. One category of such services includes safety

applications, like various types of warnings: ice on road, intersection violation, cars in front

braking, and collision avoidance and mitigation in situations like: lane changing, lane merging

and preparation for imminent collision. Another important class of applications that can be

deployed over VANETs is concerned with traffic operations and maintenance: dynamic route

planning, weather conditions publishing and adaptive signal control in intersections.


- 8 -

1.2. Backgroung and related work

The problem of finding the best route for a destination in a crowded city has been

poked at in several articles and thesis.

Some solutions are based on the learnig from experience technique[9]. After runnig a

speciffic route, the driver will manually input the time spent on in traffic, and in the future

he/she will be able to select the best route depending on the speed asociated with known

routes. These kinds of applications are somewhat limited, because they consider that the traffic

conditions are static. Thus, it is not taken into account that accidents may occur, or that

wheather conditions may have a major impact to the roads' conditions. Moreover, while

travelling in an unfamiliar city, there is no knowlage avalible for drivers to use to compute the

best route.

Other solutions process data received from various types of sensors (infrared cameras,

asphalt-integrated sensors, etc.), such as the application implemented in [10]. An expert

system is used to compute the best route instead of the classical Dijkstra algorythm. Results

have shown that the expert system is able to calculate the shortest path quicker, but it need a

large amout while computing the rule base. Also, the integration of sensors in every city

intersection is extremely costly. At the moment, applications based on such types of sensors

are used mainly on highways, and the services they provide are limited to traffic flow

adjustment.

Collaborating Route Planning in Vehicular Ad-hoc Networks[11] presents a two

solution to the problem, based on the collaboration between drivers and the exchange of

information between cars. Assuming that cars are equipped with wireless communication

devices, with processing power and with GPS devices, they can collaborate in order to

exchange information about traffic conditions and to dynamically determine which the best

route towards a destination is. The first application initially computes a static route and then,

using car-to-car communication, determines traffic conditions on the roads it will travel. When

unfavorable traffic conditions are detected, the car computes a detour avoiding the area with

problems. The second application presented was a hybrid system composed both of

infrastructure nodes and vehicles. The fixed nodes are placed in all intersections, are


- 9 -

connected and share a database with information about traffic conditions. Cars approaching an

intersection request routing information from the fixed node, communicating to it their

destination. Based on the information it has about jams and delays, the fixed node computes

the best route and replies to the vehicle with the next road segment it should go on. Although

some average travel times obtained by the first application are smaller than those produced by

the second, it can be concluded that the hybrid system is better because the times produced by

it apply to all traffic participants while the times produced by the first apply to fractions of

participants and only in specific conditions.

In [12] a solution is proposed which is based on the communication between cars,

wireless traffic lights and a central server, where cars send information about the roads'

conditions, and receive data about oher roads' conditions. The testing showed good results,

but the solution provides a main disadvantage: the central server, which holds data about all

the roads, is a real bottleneck, and if something happens to it, the whole system fails.

This thesis presents a solution for traffic congestions in cities, based on the

communication between vehicles and wireless equipments installed in

intersections(WirelessTrafficLight). Cars that are running the application permanently record

data about the road it's currently running on and the average speed it measures. Data is sent to

the WirelessTrafficLights, which aggregates data from all the vehicles that send their data.

Each WirelessTrafficLight communicates with its physical neighbours (the next

WirelessTrafficLight in each direction of the intersection) and sends them its knowlage of the

entire maps and the cost asociated with each road segment that it knows about. The way that

the WirelessTrafficLights communicate and send their data is somewhat simmilar with the RIP

(Routing Information Protocol), which is a dynamic routing protocol used in local and wide

area computer networks.

The next chapter (chapter 2) presents the simulation environment of the VANET in

which this protocol is tested. Chapter 3 briefly describes the DSRC protocol,which is designed

to support vehicle-to-vehicle and vehicle-to-infrastructure communication. Chapter 4 presents

the architecture of the TrafficView application and chapter 5 presents the results that have

been recorded while running several tests and their interpretation. The final chapter (chapter 6)

presents conclusions and future work that can be developed using such technologies.


- 10 -

2. Simulation environment

The simulation of a VANET requires 2 different components: a network simulator,

capable of simulating the behavior of a wireless network, and a vehicular traffic simulator,

able to provide an accurate mobility model for the nodes of a VANET. Recent studies [5] have

proven that the vehicular mobility model is very important, and in order to obtain relevant

results, the two components should be integrated. If an inaccurate mobility model is used, like

the popular random waypoint model (which may work for some mobile ad-hoc networks, but

is definitely not an accurate representation of mobility in a VANET), false results can be

obtained [5][6]. However, we believe the mobility model implemented in [5] or [6] is still not

an accurate representation of real vehicle mobility. Thus, the authors of [4] use real maps, in

the TIGER format [7] and their vehicles move along the streets. But each vehicle moves

completely independent of other vehicles, with a constant speed randomly chosen. Multi-lane

roads or traffic control systems are not taken into consideration. The mobility model in [5] is

more complex. It also uses TIGER files, and considers car-following models. Thus, the motion

of a vehicle is influenced by the preceding vehicle. They also implement traffic control

systems: timed traffic lights and stop signs. However, multi-lane roads are not taken into

consideration.

We have chosen to develop our own simulation tool[8], comprising the 2 previously

mentioned components: a microscopic traffic simulator, and a wireless communication model.

The entire project was implemented in Java. We have also implemented a graphical user

interface, using OpenGL for Java (JOGL). However, during most of the simulations we have

performed, we disabled it, in order to improve the simulator’s performance.

The VANET Simulator is a discrete event simulator meaning that the simulation time

advances with a fixed time resolution after executing the simulator code for the current

moment of time.

The VANET application consists of an event queue which can hold 3 types of events :

Send, Receive and GPS. A Send event for a specified node triggers the calling of the node’s

procedure responsible for preparing a message. That send event is then inserted into the Event

Queue . The Engine of the simulator checks this Event Queue at a regular fixed amount of

time , and for any Send Event found it creates one Receive Event ( if the Send Event is

Unicast ) or several Receive Events for everyone of the nodes which are in the wireless range


- 11 -

of the sender. When a Receive Event is created first the Engine checks to see if there is

another Receive Event corresponding to the same Receiver for the current simulation time,

and if it is , it adds this Receive Event to the receiver’s event list .This makes it easier when

the Receiver simulates the receive procedure of an Event , it has to check it’s Receive Event

list and chooses one according to a receive power threshold and interference level. The GPS

Event is scheduled at a regular time interval for each node thus accurately simulating the way

a real VANET application collects GPS data periodically.

Figure 3. Part of the architecture of the simulator that emulates a VANET application.

TrafficView application events in yellow

The simulator uses real digital maps, TIGER files, offered by U.S. Census Bureau. In

particular we use “.RT1” and “.RT2” files that give information about roads’ name and type,

about the latitude and the longitude of the beginning point and the end point, but also the

coordinates of some intermediary points. By parsing the information contained in these files,

we create a Java object containing all the information. Furthermore, some improvements are

also added to the map: roads are split in even smaller road segments by adding more

intermediary points and roads with the same name that are connected are merged if they don’t

form a loop.


- 12 -

Because in the TIGER files no information is given about traffic lights, after the map is

created, for each cross traffic lights or just priority signs are assigned in a heuristic manner. If

all roads in a cross are of the same type (major or secondary), a traffic light will be created in

the cross. If roads have different types, major roads will be given priority signs and secondary

roads will have to give priority. For very dense city scenarios it turned out to be better to put

traffic lights in all intersections in order to give a chance to all cars entering to pass through

the intersection because in this type of scenario cars coming on roads that have to give priority

frequently got stuck in the intersection waiting for the others to pass and having no space to

cross the intersection.

All this information is stored in a Java object, called “Map”. The object will be

serialized in a file, so that all these computations will not be performed again. We have

designed a simulator module which allows the user to interactively create various traffic

scenarios. This module is made of 2 sub-modules.

The first one will load an existing Map object (from a file) and add a list of entries and

exits. Various routes are computed between each entry-exit pair. All this information will be

stored in a Java object and serialized in a file - “Scenario 15 Map File”. This object is in fact a

blank traffic scenario that will be later configured and loaded in the simulator.

The next module will load this object from a “Scenario Map File” and provide the user

with a GUI which can be used to add traffic information on the map. The user can specify

flows of vehicles and the routes to follow between entries and exits. All the information is

stored in another Java object and serialized in a file – “Final Scenario File”. This file contains

all the information required by the simulator in order to run a specific scenario.


- 13 -

3. DSRC Protocol

Dedicated Short-Range Communications (DSRC)[12] is a promising wireless

technology which operates in the 5.9 GHz range with 75 MHz of spectrum. Its primary

purpose is to support critical safety applications which will reduce the number of accidents on

the road and as a result will reduce the number of lives lost and its secondary purpose is to

improve traffic flow , although aside from these two, private services will also be permitted.

The TrafficView application extends this protocol, adding to it the necessary

functionalities to make it work, and also the DSRC remaing functional, as well as other

protocols that extend the DSRC protocol.

DSRC has six service channels and one control channel .The control channel will be

used for the transmission and reception of “safety of life” messages and also service

advertisements and the service channels will be used for other non-safety-critical messages.

This standard is based on the IEEE 802.11a technology and as a result the physical

layer follows the same frame structure , 64 sub-carrier OFDM based modulation scheme but it

has a 10 MHz channel bandwidth and this changes the maximum data rate , timing parameters

and frequency parameters. At the MAC layer , the DSRC standard uses a 7 channel band with

a distinction between safety and non safety messages and so it implements a message priority

scheduler . Aside from these differences DSRC follows the 802.11a standard.

The motivation behind the development of DSRC is based mainly on the need for a

more tightly controlled spectrum for maximized reliability. The use of hand-held and hands-

free devices that occupy the 2.4 and 5 GHz bands along with the increase of WiFi could cause

intolerable and uncontrollable levels of interference that would significantly decrease the

reliability and effectiveness of vehicular safety applications. But even with a licensed band ,

some issues arise , such as fair access to all applications , including priority scheduling of

traffic between different application classes (safety over non-safety).Unlike 802.11 , multi-

channel coordination is a fundamental capability of DSRC.

The DSRC Protocol is implemented as an OSI stack with the Physical , MAC ,

Application Layers and it relies heavily on the 802.11 protocol stack and the 802.11


- 14 -

implementation details , but it also focuses on the differences which it has when comparing

with 802.11 , especially the differences at the Physical and MAC Layers.

Figure 4. The DSRC modules (in Blue) and TrafficView module (in yellow)

In Figure 4 , you can see the DSRC OSI Stack communicating with the old

elements in the Simulator. The Physical layer communicates with the send routine

which gets the packet , creates a new Send Event and adds it to the Event Queue

and with the receive routine which gets the Receive Event from Event Queue and

sends the message to the Physical Layer. The Physical Layer also communicates

with the Propagation modules and Noise Monitor module. The MAC Layer sends and

receives packets from/to Physical but also checks the status of the channel thru

Physical . The application Layer receives and sends packets from/to MAC. On top of

the stack there is the TrafficView application.

TrafficView Application


- 15 -

4.TrafficView Application Architecture

The application is an extension of the VNSim platform, and is developed using Java.

This application is designed and implemented for ad-hoc network computers of embeded

devices in vehicles and of wireless capable road-sided infrasctructure nodes, which

communicate between them using the DSRC wireless interface.

These wireless capable road-sided infrasctructure nodes will be located in intersections

with traffic lights, and will be reffered in the future as WirelessTrafficLights, because they

perform both capabilities of directing the traffic that flows through the intersection (traffic

light) and also has the wireless capabilities to communicate with vehicles that are equipped

with wireless possibilities.

The vehicles that are running the application, from now on reffered as

TrafficViewCars, will be the clients of this application, and will be provided with the best

route for their destination.

Now I will present the two entities that act in this application and how they

communicate, offering best routes for vehicles, based on real-time data.

When the system initializes, all the WirelessTrafficLights take into knowlage its

position on the map. Then every WirelessTrafficLight create a list of all road segments that

any car that enters the intersection can reach. These will be the road segments that are directly

accesible from this intersection. Also, if at the end of each such road segment there is another

WirelessTrafficLight, it will be added to a list that keep notice of all the direct neighbours of a

specific WirelessTrafficLight.

From now on, the WirelessTrafficLights act as routers running a protocol simmilar to

R.I.P., communicating with their neighbours and offering their local knowlage about the

network, and recomputing the best route for each road segment, consisting only of the "next

hop", witch is also a WirelessTrafficLight.


- 16 -

For such a protocol to work, each road segment has a cost asociated to it. A simple cost

formula has been chosen so as to limit as much as possible the necessary calcultions. Thus, the

cost for a road segment is the estimated time needed to reach that specific road segment. The

cost is calculated as followed: at first, a road segment has a default speed asociated; as

vehicles pass that specific road segment, they provide feedback, consiting of average speeds

measured on the road segment, and the asociated speed is modified accordingly; the cost

asociated with the road segment is a simple division between the road segment length and the

speed asociated with it, thus resulting the approximate time in witch a vehicle can pass that

specific road segment.

Initially, a WirelessTrafficLight knows only the costs to the route segments to witch it

is direcly connected, that are set to the value of 0, meaning that if a vehicle wishes to reach a

point of a route segment that is directly connectet to the WirelessTrafficLight, the best way to

reach it is going directly on that specific road segment.

Also, every WirelessTrafficLight calculates the cost asociated with each of its

WirelessTrafficLight neighbours. At first, this is done using a default speed, but afterwards it is

adjusted when receiving feedback from vehicles.

Figure 5. TrafficView Infrastructure

WTL 1 WTL 0 WTL 3

WTL 2

RoadSeg 1

RoadSeg 2

RoadSeg 3


- 17 -

For example, in Figure 5, the WirelessTrafficLight 0 will have its neighbours WTL 1,

WTL 2 and WTL 3, and each of the three road segments that that connect the

WirelessTrafficLight have an asociated standard cost (at first), depending only on the lenght of

each road segment.

The TrafficViewCar will permanently send, via broadcast, a message that has several

fields that WirelessTrafficLights will interpret. Every such broadcast message must include the

vehicle's destination and the position of the next WirelessTrafficLight on its route that the

vehicle will reach.

Also, every time a vehicle passes one route segment, it computes its average speed on

that specific road segment, and it add the speed and the road segment to two specially created

lists. These two lists are also included in the vehicle's broadcast message. Their purpose is to

provide real-time feedback regarding the traffic conditions on the route segments that the

vehicle has just passed.

When a WirelessTrafficLight receives a broadcast message from a TrafficViewCar for

the first time, it adds the vehicle's id to a list of vehicle ids.

The purpose of such a list is that after receiving a broacast message from a vehicle, the

WirelessTrafficLight must not entirely take into account the broadcast messages that will

follow from that vehicle. This is necessary, because the WirelessTrafficLight must not interpret

several broadcast messages from the same car as broadcast messages from independent

vehicles, and do the same computations several times for the same destiantion. Each vehicle id

in the list has an expiration timer associated to it, because the vehicle id must not remain in the

list forever. It is possible that the same vehicle might pass through the intersection sometime in

the future and its broadcast message must not be ignored, because it will need new routing

directions.

When receiving a broadcast message from a vehicle that has already been added to the

list, the WirelessTrafficLight will no longer compute the directions for its destination.

After adding the vehicle's id to the associated list, the WirelessTrafficLight checks if

the broadcast message contains any information about any road segment. If so, for each road


- 18 -

segment present in the broadcast message, the WirelessTrafficLight checks if the road segment

is identical to one of the road segments that provide a direct route to one of its neighbours. For

this to be valid, the road segments must also have identical directions. If the conditions are

matched, the speed asociated with that specific road segment is modified. The speed is not

changed entirely, but only adjusted by a fraction, so as to minimize the influence of malitious

users and also to provide an average of the last number of cars that passed the road segment

(as not drivers are the same, and will provide different average speeds for a road segment).

If data is received from a vehicle that contains information about other road segments

than the WirelessTrafficLight is directly connected to, it will send the data to all its

neighbours. This is a very important aspect, because there is a high posibility that when a

vehicle computes the average speed of a road segment, it will already have reached the

wireless area of a WirelessTrafficLight that is connected to the specific road segment, but at

the other end of it. For example, if a vehicle runs from WirelessTrafficLight A to

WirelessTrafficLight B, when it reaches B, it will compute the average speed on the A-B road

segment and will broadcast it. Almost certainly, the WirelessTrafficLight that will receive the

broadcast message will be B. But WirelessTrafficLight B is interested only in the B-A road

segment, and not the A-B road segment. Still, WirelessTrafficLight will send the information

to all its neighbours, because certainly one of them will be interested (in this case

WirelessTrafficLight A).


- 19 -

Figure 6. TrafficView Communication flow starting from a vehicle

When a WirelessTrafficLight receives data from a neighbour, and the information is

regarding one of the road segments that provide a direct link to one of its neighbours, it will

adjust the speed asociated with that specific route segment in a simmilar way to the one

previously described, and will recalculate the asociated cost accordingly.

All the WirelessTrafficLights have three lists that together create a structure simmilar

to a routing table. The lists consist of route segments, the costs asociated with each road

segment and the road segments that a vehicle must opt for if it wishes to reach a destination

located on a route segment from the first list.

At first, these lists are emply and must be populated. This is done in the following

way: every WirelessTrafficLight advertises to its neighbours that it can reach the route

segments direcly connected to it with a 0 cost. When a neighbour receives such an

advetisment, it checks that the advertised route segment is not directly connected, and if not,

adds the route segment to the "routing table", with the associated cost of the route segment that

must be passed to reach the neighbour who advertised the route segment (see Figure 7).

WTL 1 WTL 0 WTL 3

WTL 2

RoadSeg 0

RoadSeg 2

RoadSeg 1

RS 1; Speed 60


- 20 -

Figure 7. First route exchanges between WirelessTrafficLights

Once a WirelessTrafficLight receives information about a route to a route segment that

was not present in its local database, it will send this information to all its neighbours, throuth

another advertisment. But the new advertisment will contain a modified cost, adding to the

received one the cost asociated with the road segment witch connects the WirelessTrafficLight

with the one that initially had sent the advertisment.

This action is performed several times, until the system reaches a state of convergence,

in which every WirelessTrafficLight has in its local database all the route segments that are on

the map.

Furthermore, all WirelessTrafficLights will contiune to advertise the route segments

that are directly connected to it, so as to provide a fresh perspective to its neighbours and to


- 21 -

force them to recalculate (if necessary) the cost asociated with all the routes that required to

pass through the WirelessTrafficLight.

Figure 8. Further route exchanges between WirelessTrafficLights

To sum up, every WirelessTrafficLight will have it its local database, after the system

has reached the state of convergence, all the map's route segments, the costs and the outgoing

route segment(simmilar to next hop/interface in internet routing) asociated with each of them.

The TrafficViewCar client that periodically sends broadcast messages with the

structure previously described, will get a reply once it enters the are of a WirelessTrafficLight,

and its broadcast message is recevived.


- 22 -

The WirelessTrafficLight that receives the broadcast message from a vehicle for the

first time will check if the destination of the vehicle is located in any of the route segments of

its local database. If a match is found, the WirelessTrafficLight will send an unicast response

message to the vehicle.

The response message contains the route segment that the WirelessTrafficLight has

asociated with the route segment witch the destiantion of the vehicle is located on. This means

that the WirelessTrafficLight simply directs the vehicle to the next WirelessTrafficLight on the

route where the vehicle will also send broadcast messages and will receive the next route

segment that has to be passed through to reach the destiantion.

The fact that the WirelessTrafficLight does not calculate the entire route of the car is

an advantage in several ways. First, the WirelessTrafficLight does not have to do any real

computing. It simply checks if a point on the map is located in any of the road segments that

are in its local database, and if a match is found, it immediately send the response message

with the coresponding enty in the database. This is a very important aspect of the application

because the vehicle must receive a response before it passes through the intersection. If the

vehicle does not receive the response message before it passes the intersection, it might not

know in witch direction to go at that intersection.

Computing the entire route for a vehicle can prove to be unsuitable in a city scenario

where the traffic conditions are very dinamic and a route may not be the best avalible in only a

few minutes after it had been computed. Thus, this approach of "step-by-step" has been chosen

for implementation.

The TrafficViewCar that receives a response message can be sure that the data it had

just sent via its broadcast message has been received and interpretated by a

WirelessTrafficLight, and it is no longer necessary to keep them in the vehicle's database.

Thus, every time a TrafficViewCar receives a response message, all the route segments and

their associated speeds will be cleared form the car's memory.

When a TrafficViewCar receives a response message, it knows that it has just entered

the area of a WirelessTrafficLight. The TrafficViewCar will cease to send further broadcast

messages for a limited period of time because they are redundant, the WirelessTrafficLight


- 23 -

will not send a response message, and the TrafficViewCar local database will most certainly

be empty, as it has just been cleared when received a response message. This feature is very

important as it reduces the wireless traffic in intersections, it reduces the number of messages

the WirelessTrafficLights receive and handle, and, thus, increase the response time if the

WirelessTrafficLights.

It often happens that a particular road segment gets very congested, and all the vehicles

that pass through that road segment will report slow traffic speeds. This will induce a very

high cost associated with the road segment in the system, which will lead to the routing of cars

on alternative routes (if there are any). And it also happens that after a period of time, in

which vehicles haven’t been routed through that particular road segment, that the road

segment becomes free and cars could pass very quickly, with a low cost. But since there is no

car to pass through (because they have been routed on alternative routes), the system doesn’t

really know the state of the road segment. To prevent such problems, a periodical adjustment

will be made to all the speeds (and costs) of all road segments of the map. This adjustment

tries to draw the speed of a road segment near its standard speed, creating the possibility to

reduce the cost of a road segment that has developed a very high one. This operation’s

frequency is set so as to not create a false cost to a road segment. Its only purpose is to help

high costed road segments regain their “credibility” (lower their cost) once no vehicles wish to

pass through.


- 24 -

5. Results and Discussions

5.1. Testing Conditions

The appication was developed using two simple scenarios to test the communication

and implementation of the WirelessTrafficLights and TrafficViewCars.

The first scenario (figure 9) has only one intersection with a WirelessTrafficLight, and

was used to test the communication parameters of the application.

Figure 9. Scenario used for communication testing

Using this scenario, a minimum threshold for the wireless range of the

TrafficViewCars has been defined, studing the time needed by the WirelessAccessPoint to

process and create, if necessary, a reply for any of the vehicles that send broadcast messages


- 25 -

.

The second scenario (figure 10) allowed me to test de implementation of the

application. The scenario consists of two roads, one which is the mai road, and a second road

that can be an alternative to the first road.

Figure 10. Scenario used for implementation testing

This scenario offered vehicles to take the alternative route once the mai road had

becomed crowded or congested. Using this scenario, it has been defined how much a

broadcast message from a TrafficViewCar influences the average speed associated with a

particular road segment, and also the time between the events in which WirelessAccessPoints

try to increase the associated average speed of the neighbouring road segments.

To evaluate the performances of the application, a more complex scenario was used,

one that contains 10 roads, 25 intersections with WirelessTrafficLights, and a total of 60 road

segments.

In the simmulation the wireless range of TrafficViewCars has been increased to 400

meters (the default value for vehicles is 200 meters) to be sure that the vehicles receive their


- 26 -

next route segment before they reach or pass the intersection where the WirelessTrafficLight

is.

Figure 11. Scenario used for performace evaluation

In this scenario, the mai roads are considered the two ones that intersect in the center.

To highlight the way that the vehicles react in a realistic scenario, they will apear at three of

the ends of the mai roads, and will try to reach the fourth (vehicles come from west, north,

south and go to east).

Using this scenario, I have runned a total of 8 simulations, each running 20 or 30

simulation minutes. We will separate them into two groups: one using the TrafficView

application for car routing, and the other using static predifined routes, in which every car runs

straight on the road on which it started, and makes a turn, if necessary, in the intersection

located in the middle of the scenario. Each of these two groups is divided into two several

subgroups, as follows: the first group uses fixed signal traffic lights and the second uses

adaptive signal traffic lights[14]. The fixed signal traffic lights (non-adaptive) have a constant

cycle of lights succesions in time, while the adaptive traffic lights have the ability to adjust the

green/red time for each road segment that enters the intersection. This way, if in an


- 27 -

intersection, one segment is very congested, while the others are not, the adaptive traffic light

will allow a longer “green time” to the congested route segment.

Every subgroup is runned within the simulation at different flows of cars/lane/hour that

enter the scenario in the three point on entry.

The results presented contain the number of vehicles that have reached their

destination by a specific time in the simulation (multiples of one minute), the average time

need by the vehicles to reach their destination, the average fuel consuption, in liters/100

kilometers, and finally the total emissions resulted from the engines of the cars. To evaluate

and compare the emissions of the vehiles, I have chosen to study the carbon dioxide, which is

one of the four categories of toxic emissions of vehicles. The carbon dioxide is stated as

kilogrames/hours/car.


- 28 -

5.2. Results Obtained

Standard routing, non-adaptive traffic lights, 100 cars/lane/hour:

Time (minutes) Nr of cars Average

time(seconds)

Average fuel (L/km) Emissions(co2)

1 0 - - -

2 0 - - -

3 0 - - -

4 3 191 24.36 2099

5 12 216 24.47 1983

6 26 234 23.29 1963

7 38 249 23.88 1909

8 52 262 23.46 1876

9 70 268 23.46 1894

10 89 274 23.43 1901

11 109 282 23.31 1932

12 131 286 23.52 1924

13 156 290 23.47 1947

14 168 289 23.49 1935

15 180 289 23.43 1948

16 197 291 23.44 1940

17 223 292 23.49 1946

18 241 293 23.54 1949

19 260 292 23.56 1955

20 278 292 23.55 1957

21 295 291 23.61 1955

22 299 293 23.58 1951

23 323 292 23.53 1955

24 347 291 23.51 1950

25 367 290 23.44 1951

26 385 289 23.50 1948

27 405 290 23.55 1949

28 421 290 23.58 1948

29 427 289 23.59 1948

30 447 290 23.63 1939

Table 1: Time: 30 min; semaphore: non-adaptive; vehicle flow: 100 vehicles/lane/hour; static routes


- 29 -

TrafficView routing, non-adaptive traffic lights, 100 cars/lane/hour:


time(seconds)


1 0 - - -

2 0 - - -

3 7 88 24.73 1068

4 12 125 24.13 1409

5 27 147 23.84 1491

6 43 170 23.58 1581

7 63 178 23.69 1585

8 80 186 23.46 1595

9 104 192 23.33 1598

10 128 191 23.53 1615

11 150 194 23.49 1631

12 172 194 23.26 1616

13 195 190 23.27 1596

14 214 190 23.24 1587

15 233 188 23.16 1569

16 250 186 23.12 1553

17 280 184 22.95 1529

18 303 184 22.95 1521

19 326 182 22.93 1507

20 338 180 22.96 1499

21 357 181 22.95 1501

22 372 180 22.93 1498

23 391 181 22.88 1502

24 411 181 22.87 1504

25 431 180 22.90 1504

26 448 182 22.92 1513

27 466 183 22.91 1517

28 484 184 22.97 1529

29 500 185 22.97 1531

30 516 186 22.93 1533

Table 2: Time: 30 min; semaphore: non-adaptive; vehicle flow: 100 vehicles/lane/hour; TrafficView routing

0

100

200

300

400

500

600

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

cars reached dest

Standard

TrafficView

Vehicles that reached destination


- 30 -

0

50

100

150

200

250

300

350

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

time(simulation)

time to reach dest

TrafficView

Standard

Time needed to reach destination

0

5

10

15

20

25

30

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

fuel consuption

Standard

TrafficView

Average fuel consuption


- 31 -

0

500

1000

1500

2000

2500

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

emissions

Standard

TrafficView

Average emissions

The results show a semnificative increase in the total number of vehicles that reached

the destination before the end of the simulation as high as 15 % , and also a shorter average

time in which cars reach their destination, with a decrease of over 40 %. The comparison is

between the standard predefined routes and the TrafficView application routing.

The fuel cosumption registered a slight decrease, which can prove to be very

significant, taking into account that there are a large number of cars. Better results are

registered regarding the average emissions, with a decrease of about 20 %.


- 32 -

Standard routing, adaptive traffic lights, 100 cars/lane/hour:


time(seconds)


1 0 - - -

2 0 - - -

3 0 - - -

4 4 191 25.47 2099

5 22 207 24.08 1983

6 34 205 23.51 1936

7 54 220 23.19 1909

8 76 221 22.79 1876

9 95 226 23.00 1894

10 115 225 23.08 1901

11 134 229 23.46 1932

12 156 227 23.36 1924

13 175 227 23.63 1947

14 193 228 23.49 1935

15 217 231 23.65 1948

16 236 231 23.56 1940

17 251 232 23.62 1946

18 275 232 23.67 1949

19 296 232 23.73 1955

20 315 232 23.75 1957

21 335 233 23.74 1955

22 356 232 23.68 1951

23 376 234 23.73 1955

24 396 232 23.67 1950

25 410 233 23.68 1951

26 435 232 23.67 1948

27 457 233 23.66 1949

28 471 233 23.65 1948

29 490 234 23.65 1948

30 514 234 23.54 1939

Table 3: Time: 30 min; semaphore: adaptive; vehicle flow: 100 vehicles/lane/hour; static routes


- 33 -

TrafficView routing, adaptive traffic lights, 100 cars/lane/hour:


time(seconds)


1 0 - - -

2 0 - - -

3 8 96 25.43 1179

4 17 111 24.84 1284

5 41 121 23.87 1255

6 81 136 23.12 1312

7 97 133 23.03 1291

8 110 129 23.14 1274

9 129 130 22.86 1270

10 162 127 22.73 1252

11 179 124 22.90 1245

12 200 123 22.89 1231

13 218 130 22.94 1209

14 239 119 22.93 1210

15 249 121 22.89 1217

16 279 119 22.74 1203

17 302 118 22.84 1204

18 318 117 22.80 1193

19 329 118 22.77 1194

20 354 117 22.63 1189

21 368 118 22.66 1195

22 397 117 22.57 1186

23 415 118 22.57 1187

24 438 117 22.47 1181

25 453 118 22.50 1182

26 475 117 22.54 1185

27 492 117 22.62 1189

28 522 117 22.58 1187

29 540 117 22.61 1185

30 560 116 22.56 1177

Table 4: Time: 30 min; semaphore: adaptive; vehicle flow: 100 vehicles/lane/hour; TrafficView routes

0

100

200

300

400

500

600

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

cars reached dest

Standard

TrafficView



- 34 -

0

50

100

150

200

250

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time(simulation)

time to reach dest

Standard

TrafficView

Average time needed to reach destination

0

5

10

15

20

25

30

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

fuel consuption

Standard

TrafficView



- 35 -

0

500

1000

1500

2000

2500

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

emissions

Standard

TrafficView

Average emissions

These results show the increases in performance using the same flows of

cars/lane/hour, but, in additions, with the complementary help of the adaptive traffic lights.


the destination before the end of the simulation as high as 8 %, from 514 to 560 vehicles, and

also a shorter average time in which cars reach their destination, with a decrease of over 45 %.

The comparison is between the standard predefined routes and the TrafficView application

routing.

The fuel cosumption registered a slight decrease, with a difference of about 1 litre/100

kilometers, which can prove to be very significant, taking into account that there are a large

number of cars. Better results are registered regarding the average emissions, with a decrease

of almost 40 %.


- 36 -

Standard routing, non-adaptive traffic lights, 150 cars/lane/hour:


time(seconds)


1 0 - - -

2 0 - - -

3 0 - - -

4 3 202 26.55 2184

5 18 229 25.27 2081

6 37 250 24.76 2039

7 49 256 24.52 2019

8 65 266 24.05 1980

9 91 272 23.70 1951

10 115 275 23.78 1958

11 136 280 23.69 1950

12 158 283 23.56 1940

13 182 284 23.47 1932

14 191 284 23.49 1933

15 212 286 23.50 1935

16 234 287 23.59 1942

17 256 290 23.53 1937

18 282 292 23.54 1938

19 305 295 23.51 1936

20 327 295 23.45 1931

Table 5: Time: 20 min; semaphore: non-adaptive; vehicle flow: 150 vehicles/lane/hour; static routes

TrafficView routing, non-adaptive traffic lights, 150 cars/lane/hour:


time(seconds)


1 0 - - -

2 0 - - -

3 4 78 26.34 995

4 15 130 26.23 1465

5 37 167 24.66 1593

6 68 179 23.72 1572

7 109 184 23.75 1580

8 132 190 23.58 1589

9 157 192 23.54 1600

10 185 196 23.48 1607

11 219 195 23.50 1606

12 261 199 23.40 1619

13 292 197 23.44 1615

14 312 197 23.47 1614

15 337 197 23.42 1612

16 361 198 23.42 1615

17 388 200 23.34 1615

18 421 203 23.31 1624

19 458 206 23.36 1640

20 484 206 23.41 1646

Table 6: Time: 20 min; semaphore: non-adaptive; vehicle flow: 150 vehicles/lane/hour; TrafficView routes


- 37 -

0

100

200

300

400

500

600

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

time

cars reached dest

Standard

TrafficView


0

50

100

150

200

250

300

350

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

time

time to reach dest

Standard

TrafficView



- 38 -

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

time

fuel consuption

Standard

TrafficView


0

500

1000

1500

2000

2500

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

time

emissions

Standard

TrafficView

Average emissions

These results show the application performances using a different flow, of 150

cars/lane/hour, without the complementary help of the adaptive traffic lights.

The results show an increase in the total number of vehicles that reached the

destination before the end of the simulation as high as 45 %, from 327 to 484 vehicles, and

also a shorter average time in which cars reach their destination, with a decrease of about 30%.


routing.


- 39 -

The fuel cosumption registered an unsginificant decrease. Better results are registered

regarding the average emissions, with a decrease of about 14 %, from 1931 to 1646

kilogrames of carbon dioxide/hour.

Standard routing, adaptive traffic lights, 150 cars/lane/hour:


time(seconds)


1 0 - - -

2 0 - - -

3 0 - - -

4 4 202 27.63 2276

5 22 221 25.74 2119

6 47 226 24.13 1986

7 74 229 23.88 1965

8 99 229 23.61 1944

9 125 230 24.09 1983

10 156 231 24.01 1977

11 169 232 24.27 1998

12 200 232 23.88 1966

13 217 235 24.00 1976

14 249 235 23.75 1955

15 271 236 23.87 1966

16 297 238 23.86 1965

17 315 239 23.84 1963

18 348 237 23.75 1955

19 367 239 23.79 1959

20 395 239 23.75 1955

21 415 240 23.77 1957

22 443 241 23.67 1949

23 456 242 23.66 1948

24 490 247 23.65 1947

25 510 247 23.68 1950

26 537 250 23.64 1947

27 556 249 23.69 1951

28 584 249 23.64 1947

29 607 252 23.73 1954

30 653 253 23.75 1956

Table 3: Time: 30 min; semaphore: adaptive; vehicle flow: 150 vehicles/lane/hour; static routes


- 40 -

TrafficView routing, adaptive traffic lights, 150 cars/lane/hour:


time(seconds)


1 0 - - -

2 0 - - -

3 10 72 25.78 921

4 21 114 24.24 1221

5 63 124 23.87 1228

6 116 141 23.15 1307

7 150 139 23.09 1283

8 177 133 22.99 1245

9 204 134 22.87 1253

10 244 130 22.63 1230

11 268 130 22.57 1225

12 300 126 22.60 1208

13 325 125 22.53 1202

14 368 123 22.52 1190

15 392 122 22.59 1186

16 424 121 22.45 1179

17 451 119 22.50 1164

18 490 118 22.36 1154

19 512 118 22.43 1155

20 533 117 22.47 1152

21 564 116 22.55 1155

22 600 117 22.40 1157

23 630 117 22.40 1153

24 665 116 22.40 1150

25 681 116 22.41 1148

26 718 116 22.42 1150

27 744 116 22.46 1153

28 780 116 22.45 1155

29 807 116 22.41 1151

30 840 115 22.40 1149

Table 4: Time: 30 min; semaphore: adaptive; vehicle flow: 150 vehicles/lane/hour; TrafficView routes

0

100

200

300

400

500

600

700

800

900

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

cars reached dest

Standard

TrafficView



- 41 -

0

50

100

150

200

250

300

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

time to reach dest

Standard

TrafficView


0

5

10

15

20

25

30

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

fuel consumption

Standard

TrafficView



- 42 -

0

500

1000

1500

2000

2500

1 3 5 7 9 11 13 15 17 19 21 23 25 27

time

emissions

Standard

TrafficView

Average emissions

The results show the increases in performance using the same flows of 150

cars/lane/hour, but, in additions, with the complementary help of the adaptive traffic lights.


the destination before the end of the simulation as high as 8 %, from 514 to 560 vehicles, and

also a shorter average time in which cars reach their destination, with a decrease of over 45 %.


routing.

The fuel cosumption registered a slight decrease, with a difference of about 1 litre/100

kilometers, which can prove to be very significant, taking into account that there are a large

number of cars. Better results are registered regarding the average emissions, with a decrease

of almost 40 %.


- 43 -

6. Conclusions and future work

The TrafficView application offers a viable model of traffic optimization in urban

congested scenarios, always finding, in a dinamic way, the route with the shortest time to

reach the destination. The application was tested wihin the scenario that simulates the

movement of vehicles that come from three directions and all try to reach the same

destination. The simulations varied by means of vehicles flow, traffic lights types and routing

types. Each simulation lasted from 20 to 30 minutes and all the diferences regarding time to

destiantion, fuel consumtion, cars that have reached their destination and emissions have been

monitored and compared.

The application manages to adjust the traffic flow on monitored road segments so as to

avoid congestions. Whenever a road segment starts to provide lower average speeds for

vehicles that pass through, the application provides alternatives on routes less congested and

with a better time to destination.

The average time needed for vehicles to reach their destinations registered a significat

decrease of about 40 %, compared with the time needed for vehicles to reach their destination

unsing predefined routes. This is explained by the fact that vehicles tend to aviod all congested

road segments and opt in favor of less congested streets.

The increase of total number of vehicles that have reached their destination by the end

of the simulation varied from 8 % to 45 %. The fact that more vehicles have reached the

destiation faster also provides less congested roads for the vehicles to come,

The average fuel consuption registered ecconomies as high as 1 litre per 100

kilometeres, which is a major advantage, taking into consideration the fact that many millions

of vehicles could benefit from the application, and the fuel saving would be enormous.

The total emissions also show a high decrease, because of the less fuel consuption and

the fewer accelerations and brakes that vehicles need to apply. The emissions’ decrease vary

form 14 % to 40 %. This can prove to be a major improvement in large cities and

metropolises, because of the improvement of air quality and, thus, the population’s health and

well being.


- 44 -

Also the traffic fluency doesn’t force drivers to accelerate and brake as often as

without using the application, which increases the cars’ fiability and provides lower upkeep.

In the matter of security, the presence of malitious users doesn’t significantly affect the

application’s performaces beacause a malitious users is taken into account only once per road

segment, and it’s influency to an average speed associated with a road segment is limited.

Future work

The system can be improved by adding to the application the option of traffic

predictibility, which provides predictability to the system. This add-on can be implemented

only if the majority of vehicles are equipped with wireless capabilities and run the application

protocol.

Furthermore, high priority vehicles such as fire trucks, ambulances and police cars,

could reach their destination much faster if their shortest path is seen to all other vehicles as

very congested, and thus the route segments that the high priority vehicles need to pass

through will be fairly free.


- 45 -

7.References

[1] http://en.wikipedia.org/wiki/Traffic_jam

[2] http://en.wikipedia.org/wiki/Transportation_Demand_Management

[3] http://en.wikipedia.org/wiki/Automated_highway_system

[4] RFC 1058, (RIP)

[5] D.R.Choffnes and F.E. Bustamante – “ An Integrated Mobility and Traffic Model for

Vehicular Wireless Networks”. In Proc. of the 2nd ACM International Workshop on

Vehicular Ad Hoc Networks (VANET), September 2005.

[6] A. Saha, D. Johnson – “ Modelling Mobility for Vehicular Ad-hoc Networks” - ACM

International Workshop on Vehicular Ad Hoc Networks (VANET), 2004.

[7] US Census Bureau, Topologically Integrated Geographic Encoding and Referencing

system (Tiger Line) - http://www.census.gov/geo/www/tiger.

[8] Liviu Iftode, Tamer Nadeem, Sasan Dashtinezhad, Chunyuan Liao – “TrafficView:

Traffic Data Dissemination using Car-to-Car Communication”, IEEE International

Conference on Mobile Data Managment, 2004.

[9] Bin Liu – „Using Knowledge to Isolate Search in Route Finding”. International

Joint Conference on Artificial Intelligence, pp.119-125, 1995.

[10] G. Eggenkamp, L.J.M. Rothkrantz – “Intelligent dynamic route planning”. KBS

& TRAIL Workshop, June 2001.

[11] Diaconescu St. Raluca – „Collaborating Route Planning in Vehicular Ad-hoc

Networks”, Diploma thesis, 2006.


- 46 -

[12] Ichimescu Andrei - " Optimizarea traficului în aglomeraŃii urbane", Diploma thesis.

[13] Cristian Aurelian Petroaca - "Vehicle Ad-Hoc Networks Dedicated Short-Range

Communication Protocol", Diploma thesis, 2007.

[14] Victor Gradinescu – “Vehicle Ad-hoc Networks Adaptive Traffic Signal Control”,

Diploma thesis, 2006

Documents

Universitatea Politehnica Bucuresti Facultatea de ...cipsm.hpc.pub.ro/documentation/Dragoi_Vlad.pdf · Universitatea Politehnica Bucuresti Facultatea de Automatica si Calculatoare