Introduction
Finding the best route to destination in congested roads traffic is a major challenge in the attempt to improve traffic conditions. The key point is the ability to detect congested roads before taking part in the congestion. We call congestion a situation on road networks where citizen’s demand in terms of road utilization exceeds the network capacity. This undesirable event has many harmful effects [1] such as longer travel times, lower security level [2] and increased fuel consumption.
In recent years, much research has been done on the issue of congestion detection. Most of these studies rely on VANET (Vehicular Ad-hoc NETwork) approaches which mainly include two types of communication: V2I (vehicle-to-infrastructure) communication and V2V (vehicle-to-vehicle) communication. Vehicles and infrastructure units are equipped with devices capable of short-range wireless connectivity. These devices can form a particular mobile ad-hoc network: VANET. Although borrowing WMSNs (Wireless Mobile Sensor Networks) techniques to VANETs, seeing their similarities, seems to be attractive, VANETs still suffer from many network issues such as bandwidth saturation and redundant data [3], late and wrong congestion level evaluation [4], and reliability problems [5].
In this paper, we propose a novel cost-effective load balancing approach which aims to distribute vehicles equitably upon a road network by notifying drivers about congestion levels of road segments.
In our approach, direct communication between vehicles does not exist anymore, which saves considerable cost regarding communication devices on the one hand, and avoid network related problems on the other hand. In fact, vehicles coordinate and share traffic reports through indirect communication. This principle, which takes inspiration from social insects, considers the environment as a medium through which communications are performed.
Through RSUs (Road Side Units), vehicles share their traffic reports and learning about congestion levels of road segments. The intelligence which emerges from such simple interactions allows vehicles to draw a traffic map converging to the real-time traffic map of the studied area.
Equipped with a navigation system and a digital map, drivers are notified about road segments where congestion levels are reported to be high to avoid them. Hence, high level congestions are prevented and a smooth vehicles distribution is guaranteed.
This paper is an extension to our previous work [6] which exposes theoretical background behind our approach. This paper recalls the fundamentals of the approach and provides proof of concept and performance evaluation. In fact, we have conceived a road traffic simulator based on Repast toolkit [7]. The proposed approach is then simulated and evaluated as described in section 9.
Related work
Communication between vehicles has been studied by many researchers in order to reduce traffic congestion. Varaiya [5] introduced a concept called ‘platoon’ where vehicles have sufficient intelligence to keep a minimum safe distance to the vehicle in front. The advantage of this approach is that the use of the road is improved, but this concept cannot prevent or unveil high level congestion segments over the whole network.
In addition, Mamei and al. [9] have conceived a navigation aid algorithm. Vehicles autonomously calculate less congested paths to their destinations based on traffic information provided by RSUs. Besides, Shah and al [1] discuss the vehicle scheduling problem. It tries to schedule vehicles trips so that the average travel time is minimized. However, both approaches are not adapted to high traffic density scenarios.
Moreover, Dimitrakopoulos and al. [2] introduce cognitive management functionalities based on V2V communication using WMSNs mechanisms. The goal of the approach is to issue directives to drivers as well as to the overall transportation infrastructure to prevent congestion situations. As mentioned in the introduction, V2V communication suffers from many network problems such as bandwidth saturation and redundant data problem. In addition, short-range wireless communication technologies make it impossible to detect real-time level congestions of remote segments.
Finally, Bauza and al. [10] present and evaluate a technique called CoTEC (CoOperative Traffic congestion detection) based on V2V communication. Although results are interesting in case of high rates of V2V penetration, CoTEC suffers from the same V2V communication drawbacks cited above.
Vehicle device
Each vehicle within the studied area is fitted with a controller device which performs two main functions: 1) visualizes high level traffic congestion segments in a road map to the driver and 2) performs calculations related to its self load-balancing algorithm (see next section).
Therefore, the vehicle controller device consists of the following components:
A GPS receiver, a digital map, and a navigation system
An IEEE802.11 transceiver, ultrasonic sensors and an embedded logic
The vehicle controller device performs simple tasks consisting in monitoring its environment by calculating congestion levels of visited roads Fig. 1. Through interactions with RSU controllers, a load-balancing intelligence emerges notifying drivers about the most congested roads to avoid them.
Figure 1. Vehicle device ultrasonic sensors
The vehicle device is connected to ultrasonic sensors which detect objects and measure the distance to them as described in figure 1.
Congestion level formula
The congestion level (CL) formula is established as the weighted average of distances delivered by ultrasonic sensors. Weights are attributed to sensors depending on their installation position and thus on their influence in determining a congestion situation.
Let’s consider a vehicle equipped with n ultrasonic sensors ().
Since the environment is moving, it wouldn’t be of great benefit to calculate instant distance to any encountered obstacle. Instead, we define a damping time parameter called DT (Damping Time) during which average distances are calculated. If we set the DT to 60s for instance, then an will continuously calculate the average distance to encountered obstacles from current time to last 60 seconds. The CL formula is defined as follows:
(1)
Where is the average distance returned by the from t time to last DT seconds and is the weight attributed to . Note that function has an upper limit and a lower limit .
In practice, DT parameter as well as USs’ weights are determined with regard to the road network wherein the proposed approach will be deployed: in downtown scenarios, the DT is defined bigger than it is defined in highways scenarios since the average distance travelled during a DT is smaller in the downtown than it is in the highway, remember that a congestion level is reported according to a location, at most to a limited road segment (see Section 6).
To illustrate the idea behind our work, let’s consider a left-hand drive vehicle with 4 USs in a downtown scenario, each sensor is placed in the middle of a different side (See figure 1). The left sensor is more unveiling than the right one and the rear sensor is more unveiling than front one. So, according to this rule, USs weights could be defined as follows: weights 2 are given to the left and rear sensors, and weights 1 are given to the front and right sensors. We can set to 5 meters, to 1 meter and the damping time to 60s. USs are indexed as shown in figure 1. Therefore, the congestion level formula becomes:
(2)
According to this function, we can define typical levels of congestion:
High: nearby obstacles are averagely detected at least at 3 sides: the front, the left and the rear sides, so the calculated threshold is expressed as: . Therefore, congestion levels greater of equal to 0.6 are considered to be high.
Medium: nearby obstacles are averagely detected at least at 2 sides: the front and the rear sides, so the calculated threshold is expressed as: . Therefore, congestion levels within [0.33, 0.6[interval are considered to be medium.
Low: nearby obstacles are averagely detected at least at 1 side: the front one, so the calculated threshold is expressed as: . Therefore, congestion levels within [0.23, 0.33[interval are considered to be low.
Other rules in expressing typical congestion levels or attributing sensors’ weights may be considered as well. The purpose of the above-cited example is to clarify and show the flexibility potential of the approach.
In the remainder of this article, a location is considered to be relatively congested if the CL exceeds a predefined threshold called CLT (Congestion Level Threshold).
Roadside units (RSUs)
RSUs are computing devices located on the roadside that provides connectivity support to passing vehicles. They are fitted in roadside poles such as traffic lights controllers. Their role is to offer a communication medium to vehicle devices in order to share knowledge about traffic levels of road segments (see figure 2).
Figure 2. Vehicle/RSU synchronization
RSUs consist of an IEEE802.11 transceiver and an embedded system. When a vehicle is within the transmission range of a RSU, it establishes a connection to it and synchronizes its KB (knowledge base) with the RSU shared memory. The latter contains processed data about every vehicle KB which has run within its transmission range. In this way, vehicles’ KBs are kept updated about the whole traffic map of the studied area.
Vehicle device algorithm
A vehicle device monitors its environment for two main events: 1) CLT reached and 2) a RSU detected, as shown in the manager flowchart in figure 3.
Figure 3. Vehicle congestion manager flowchart
If the CLT is reached, which means that the vehicle’s location is relatively congested and more likely to get congested in the near future, then the controller retrieves its GPS location and current datetime. This information is passed to the VSB (Vehicle Segment Boxer) function to be processed as described in the following algorithm (see Algorithm 1)
Function VSB(position, datetime)
Begin
iBoxgenerateInitialBoxPolygon(position)
for each entry in VKB Do
if isObsolete(entry) then
VKB.delete(entry)
else
if areMergeable(iBox,entry.box) then
entry.boxmergeBoxes(iBox,entry.box)
entry.datetimedatetime
return
end if
end if
end for
VKB.add(new Entry(iBox,datetime))
End Function
Algorithm 1: Vehicle SB function
A main drawback of several contributions in this field is redundant location data which rapidly turns into flooding bandwidth if it is not carefully investigated. To overcome such a problem, we have got inspired by a simple concept which allows storing a huge amount of location data in small-sized blocks. The idea is that a geographically bounded area, which can be stored as locations of its edges, contains infinite locations which cannot be stored any way. So, instead of storing locations, storing areas is a much more efficient alternative.
So, the VSB function consists in generating an initial box including the GPS location. A box is a geographical rectangle which represents a relatively congested segment and whose size may grow up to cover other boxes in its vicinity. In this way, storing space is optimized by updating existing boxes instead of storing new ones.
So, after generating an initial box, the VSB function browses all entries within the vehicle KB. A KB contains information about vehicles traffic reports, i.e. high level congestion segments. It is composed of entries, and each entry contains a box, which represents a relatively congested road segment, combined with the most recent datetime the congestion level was reported.
While browsing entries of the KB, the VSB function checks each entry for obsolescence. If it has been some time limit since the entry (mainly its datetime) was not updated, it is considered to be obsolete and removed from the KB. If it is not obsolete, then it is compared with the initial box through the areMergeable function. The latter consists in checking if the initial box can merge with an existing box. Cases where two boxes can merge into one box are the followings:
Either one box includes or intersects with the other
The two boxes are geographically close
If the two boxes meet one of the above conditions they are merged together into one box. The latter overwrites the former boxes in the KB and its datetime is updated. If they cannot merge, then the function iterates to the next entry and repeats the same logic. After browsing all entries and no convenient box is found, the function creates a new entry in the KB where it stores the initial box.
If a RSU is detected, then the vehicle controller connects to it and launches a synchronization process as described in figure 4.
Figure 4. Vehicle/RSU synchronization flowchart
The synchronization process consists in synchronizing the RSM (RSU Shared Memory) and the VKB (Vehicle KB). The RSM is a memory contained in each RSU which contains information about high level congestion segments. It is kept updated by vehicles as they drive within its transmission range. The RSM has the same data structure as the VKB.
For the synchronization process to success, connection time between the vehicle device and the RSU should be as short as possible. This is why data processing is done asynchronously by both units after exchanging their KBs (see figure 4).
When a vehicle device receives a RSM, it launches a SB (Segment Boxer) thread which consists in updating the vehicle KB based on the received RSM. It browses all entries within the RSM and checks whether they can be merged with any existing entries in the vehicle KB. If no entries are found, they are added to the vehicle KB. It should be noted that this treatment may be time consuming; this is why it is performed by a background thread.
RSU algorithm
RSUs serve as servers to vehicles’ devices. When a vehicle device is within the transmission range of a RSU, it tries to connect to it. Therefore, the RSU creates a server thread to perform all operations requested by the vehicle controller. When receiving a vehicle KB, the RSU updates its RSM based on the received KB through the RSB (RSU Segment Boxer) function (see algorithm 2).
Function RSB (VKB)
Begin
writeLock(RSM)
for each vEntry in VKB Do
flagtrue
for each rEntry in RSM Do
if areMergeable(vEntry.box,rEntry.box) then
rEntry.boxmergeBoxes(vEntry.box, rEntry.box)
rEntry.datetime(vEntry.datetime>rEntry.datetime)? vEntry.datetime: rEntry.datetime
flagfalse
break
end if
end for
if flag then
RSM.add(vEntry)
end if
end for
releaseWriteLock(RSM)
End Function
Algorithm 2: RSU SB function
The mechanism of synchronization is the same as that of the vehicle controller, except for one feature: during the updating process, the RSB function locks the RSM for writing. In this way, data coherence is guaranteed and concurrent accesses are managed. Vehicle controllers can read the RSM content but cannot update it until the lock for writing is released.
While the RSU doesn’t exceed a certain predefined threshold based on the number of simultaneously connected vehicles, it periodically launches the SSB (Segment Self Boxer) background thread as shown in figure 5.
Figure 5. RSU congestion manager flowchart
The role of the SSB thread is to maintain the RSM optimal and cleaned from any obsolete entries. The SSB thread browses all RSM entries looking for any possible merging between them. In this way, space storage is optimized by reducing the number of RSM entries as well as its processing time during synchronizations.
Traffic simulator
To prove the efficiency of our model, we have conceived a traffic simulator based on Repast toolkit [7] and java programming as shown in figure 6.
Figure 6. Repast Traffic Simulator
Repast Symphony [11] is a widely used, free and open source agent-based modeling environment that has collectively been under continuous development for over 14 years. Agent-based modeling provides a mechanism for modeling Complex Adaptive Systems (CASs) [12-15] in many disciplines such as economics, military and biology. Repast was originally developed by David Sallach, Nick Collier, Tom Howe, Michael North and others at the University of Chicago [15].
The simulator consists of a grid road network. Each intersection of the grid is fitted with traffic signals. Cars are initially generated at the bottom-left point of the grid and they are programmed to achieve the top-right corner using an available road segment. They move forward if they are not at a red light or behind another stopped car. All cars drive at a constant same speed. In intersections, cars can change direction if blocking cars are in front of them. If a car reaches its destination, it drops out of the simulation freeing space to others. Every path to the destination point is of equal distance.
Performance evaluation
The simulation consists in generating 100 cars at the bottom-left point of the grid and waiting until the last car achieves the top-right point of the grid. Since all paths are of equal distances and cars drive at the same constant speed, the key parameter to measure the efficiency of the traffic management is the average time taken by all cars to achieve their destination.
In the first scenario, the traffic management will be assured only by traffic signals which will be all synchronized: signal colors alternate from the N/S direction to the E/W direction but are the same in each direction (see figure 7). Signal colors alternate each 30 ticks of the simulation.
After simulation, we notice that the network is not well exploited; cars are concentrated in the middle of the network which causes traffic congestions slowing down the overall speed. Figure 7 shows the state of the roads at tick 136.
Figure 7. Road network at tick 136, traffic signals management
The first simulation has required 430 ticks until the last car achieved its destination, which is far from being optimal.
The second simulation will run under the same conditions except for the fact that cars and traffic signals will implement our approach for self load-balancing. We define a segment as the road which links between two consecutive intersections. Each segment has its own coordinates (see figure 8).
Figure 8. Marking grid segments
Cars are fitted with front and back ultrasonic sensors. The car business logic consists in calculating and storing the congestion levels of visited roads. At intersections, cars exchange information about congestions levels with RSUs located in traffic signals. In this way, cars get notified about segments of the network that are getting congested to avoid them.
Figure 9. Road network at tick 136, self-load balancing management
We notice that cars exploit the road network more efficiently. Figure 9 highlights cars behavior at tick 136. Each time that a segment begins to get congested, it is reported to other cars through RSUs. The simulation has lasted only 300 ticks until the last car achieves its destination.
Conclusion
In this paper, we demonstrate the efficiency of the self load-balancing approach applied to the traffic congestion problem. In fact, through stigmergy concept borrowed from social insects, vehicles load-balance themselves by notifying drivers about congested road segments to be avoided. In this way, all the network roads are efficiently exploited preventing high congestion situations.
V2V communication, which faces many technical and cost-related challenges, is abandoned. Instead, the proposed approach resorts to indirect communication between vehicles (stigmergy). In fact, RSUs serve as a medium through which vehicles exchange traffic reports and synchronize their knowledge bases. A key problem facing such an approach is data storage and exchange which theoretically should be optimized as much as possible. Therefore, optimization algorithms based on computational geometry are proposed and described.
The load balancing algorithm is not explicitly programmed, but it emerges as a result of several interactions between vehicles and the environment.
The proposed approach is implemented and simulated under Repast toolkit. Results of the performance evaluation were very encouraging. Further work on the approach aiming to apply it in a real test field is under study.