Dynamic traffic-light phase plan protocol (DT3P)

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/261084980 Dynamic traffic-light phase plan protocol (DT3P) Conference Paper · December 2011 DOI: 10.1109/SCOReD.2011.6148726 CITATIONS READS 0 61 4 authors, including: Maythem Kamal Abbas Madzlan Napiah 13 PUBLICATIONS 9 CITATIONS 77 PUBLICATIONS 98 CITATIONS Asia Pacific University of Technology and Innov… SEE PROFILE Universiti Teknologi PETRONAS SEE PROFILE Samir Brahim Alfaisal University 75 PUBLICATIONS 325 CITATIONS SEE PROFILE Some of the authors of this publication are also working on these related projects: rheology of bituminous mixtures View project Using rice husks powder to upgrade the rheological properties of bitumen binder View project All content following this page was uploaded by Madzlan Napiah on 05 September 2014. The user has requested enhancement of the downloaded file. All in-text references underlined in blue are linked to publications on ResearchGate, letting you access and read them immediately. Dynamic Traffic-Light Phase Plan Protocol (DT3P) Maythem Kamal Abbas[1], Mohammad Noh Karsiti[2], Madzlan Napiah[3], Brahim B. Samir[4] [1][2] Electrical and Electronic Engineering Department [3] Civil Engineering Department [4] Fundamentals and applied science Department Universiti Teknologi PETRONAS Abstract - Traffic Congestion has become a major problem for urban areas. It would occur according to the road limitations and the technologies used on road and intersections. Accordingly, the traffic flow is not being run properly (vehicles delay & traffic congestion) and reduces the throughput at the intersections. We are taking the opportunity of using Intelligent Transportation Systems (ITS) to overcome the road limitation resultants. We are proposing a system design with its protocol and set of algorithms to help balancing the road traffic load and make the driving on highways and urban cities roads more comfort. Initially, the system has five main devices which would co-operate together to provide safety, assistance, and comfort for the drivers. By applying this system on roads, we expect to see an easy traffic flow and more efficient and comfort driving. Chosen application results were obtained from simulation studies, are compared with our system to show the significance or the need for the proposed system and its protocol's control actions and strategies. The paper concludes with a brief discussion of future needs in this important technical area. Keywords - Motorway Traffic Management Techniques; Traffic Load Management; Vehicle-To-Infrastructure Communication (V2I); Vehicular Ad-hoc Network (VANET). I. INTRODUCTION Vehicular Ad-Hoc Network (VANET) is a form of Mobile Ad-Hoc Network, originally was used to provide safety and comfort for passengers, and currently being used to establish dedicated short range communications (DSRC) among nearby Vehicles (V2V Communications) and between vehicles and nearby fixed infrastructure equipments; Roadside equipments (V2I Communications). VANET.[1] The VANET ideally works in an integrated environment as shown in Figure 1.[2] In this project, VANET is being employed to help in collecting traffic data from the road for the traffic light controllers to manage the traffic light phasing, timing and ease the traffic flow. A. Objective Of The Study It's an objective of this project to design hardware architecture (On-Vehicle and On-Road devices) for creating and collecting data from road and the objects on that road. Another objective is to create a protocol to process the collected data (in the first objective). A further objective would be writing an algorithm to make an optimum decision for the traffic light phase plan. A final objective is to reduce Co2 production and reducing the fuel consumption. B. Motivation Many factors have motivated us to propose such system’s architecture and the protocol, starting with the inexistence of such common architecture to be used by researchers to develop more VANET applications. Car manufacturers are about to take a quantum leap in terms of enhancing driving safety and comfort but they are waiting for new technologies and applications to be created and experimented so they can use with their products. Our system’s architecture can be an important & a unique part of that future leap. The global warming and air pollution are increasing. New methods and technologies are needed to reduce them. One way to do so is to ease the traffic flow at intersections and to not let vehicles stop for long time at traffic lights. C. Problem Statement In this project, We consider the problem of finding the best integrated traffic signal phase plan at a single intersection. D. Scope of the Study Figure 1. VANET Integrated Infrastructure VANET was used also to warn drivers of collision possibilities, road sign alarms, auto-payment at road tolls and parks. Most of ITS (intelligent transportation Systems) applications use The proposed system, would be helpful for collecting data from all roads reaching the same intersection, Figure 2, and process those data to make a decision about the optimum phase plan. The hardware of the system has five main devices; Coordinator Device (Co_D) to be placed at the beginning of a road, Road Side Equipments (RSE) to be set up along the road, Traffic-Light Controller (TLC) that each intersection has its own, VANET Road-Belt (VRB) to be placed under the road,[3], and the Vehicle VANET Device (VVD) which is an on-vehicle device that can be programmed only by authorized people. Based on the suggested architecture, a set of algorithms are patched together to act as a protocol for traffic flow enhancement. The above system can be applied on any type of roads as long as it has traffic light on. Figure 2. System Hardware setup II. LITERATURE REVIEW With the recent advances in wireless technologies, car manufacturers are about to take a quantum leap in terms of enhancing driving safety and comfort by allowing vehicles to communicate with each other and with the roadside infrastructure. So that, many projects are in progress using VANET aiming more safe highways and more comfort driving. While historically, many researches were done targeting the same goals but according to their limitations they couldn't accomplish optimal results as expected. Plenty of previous research examples are listed after we list here the most common limitations in them: 1- Suggesting to centrally control the traffic light phasing by collecting the road traffic information from all around a city, send them to the Master controller through a communication media then process it. This will not always help to solve the congestion problem according to the delay that would be cause by the huge amount of data to be processed at once. 2- Using a camera to capture the road picture or a video then analyze what was captured. This method will not always working as it would fail during the heavy raining, foggy, or sand storm weather, and at very dark or unlined road. At its best case, cameras are able to detect whether the vehicle queue length is long or not and approximately estimates the length. This would not be so accurate and would fail when the vehicles queue is very long as the camera's sight will not be able to distinguish between a car and another. 3- Using GPS has a limitation in terms of service reception while driving inside a modern city which has a lot of long buildings. So, the GPS might fail down to estimate the vehicles queue length if the GPS receiver was in tunnel or there are a lot of clear-sky-view-blocking objects. A. Traffic Flow Enhancement and Congestion Problem Historically, many Researches, technologies and transportation systems aimed at decreasing traffic congestion on roads as part of providing comfort driving, have suffered from a lack of incentive for early adopters. For example, [4] which had suggested to control the traffic light phasing in a city from a central office named "Master Controller". In addition to the limitation of the centralized control, using rented telephone Lines would be very costly. Another example might be the work proposed by [5] that would estimate the road average speed by placing two sensors on one part of a road of a given length L, and the results of such a system will not be as accurate as much as if each vehicle declares about its own speed so that the vehicle arrival time to the traffic light would be almost an exact. Some other solutions were proposed to avoid or reduce traffic jam on roads. if we have a look to [6] and [7] works, both offer providing drivers with road congestion data only will solve the congestion problem on a road. According to our opinion, this solution will not necessarily solve the congestion problem on the road as it might fail in some cases, for example, when many drivers want to approach a destination which has only one way to reach to, the proposed solution will not help the driver to avoid the congestion nor ease the traffic flow. Many researchers have argued that an image processing solution would be optimum to solve the congestion problem. (e.g. [8], [9], [10], [11], [12], [13], [14], and [15]). they were looking for a solution for Traffic congestion problem by applying some Image Processing Methods to detect the amount of congestion on streets by using video or picture cameras. Several studies have found good solutions for the congestion problem, such as; [16] and [17], but their systems might not give accurate results as they depend on few input variables while ignoring others. example on that, in [17], they have tried to predict the traffic flow depending on time only or Vehicle Queue Length only, that might help to solve the problem of traffic congestion and enhance the traffic flow, but it might fail in some cases as they have missed other factors those might help them to make their prediction more accurate, such as, the traffic load on the previous traffic light, and the traffic load on the next traffic light. Using GPS, was one of the technologies used by a number of researchers to solve the traffic jam problem. The [18] work can be considered as an example when they have used GPS to detect the on-road vehicles speed and control the traffic light to enhance the traffic flow. but GPS has the limitation as mentioned before. B. Lane Detection In 2002, Lee et al. has published their patent named as "Control System To Prevent Lane Deviation of Vehicle and Control Method Thereof", in which they have introduced a system that would make the use of a camera mounted to the vehicle to capture pictures of the upcoming road, analyze the captured pictures and detect a lane deviation. which is inefficient as we have mentioned before. For the same reason above, all of [12], [14], and [19] would fail as they all use camera to capture pictures or videos to detect road's status. in [19], they are using GPS to help the camera to do the detection job and it will not be an optimum solution as GPS has its own famous limitation. 8. Calculating the load on each lane of the road. D. Decision Making Stage 9. Comparing the Load values and making a new phase plan. The next sections explaining each stage deeper. A. Early RDC Stage Two operations would take a place in the early RDC stage, the number of vehicles (entering the road) detection and the vehicles identification. by referring to Figure 4, When a vehicle (ΔAx) enters a road, it would step over the Road Belts (βA) which is placed on the road's entrance ground. The Road-Belt would do the job of detecting the entering vehicle then forward an electronic signal to the RSE (ΓA1) it is connected to. The RSE would do the counting job. Repeatedly, the total vehicles count (LN) would be sent to the last RSE on road (ΓAL) within a message type AH (MtAH), as the last RSE is the one which is responsible to calculate the overall road's load and communicate with the traffic light controller at the intersection. The second operation would start when the RSEs regularly broadcasting its existence through hello message type AA (MtAA). When a vehicle (ΔAx) receives the broadcast MtAA, it would check whether it has previously received a hello message from an RSE resides on the same road. Vehicle enters a road 4 5 6 7 8 9 Road Data Collecting 3 Load Decision Calc. Making Figure 3 shows the DT3P Protocols stages, those are: A. Early RDC Stage 1. Vehicle Detection (By VRB). 2. Vehicle Registration (By Messaging with RSE). 3. Emergency Case Presence checking (By RSE) - This stage out of this paper scope. B. Late RDC Stage 4. Estimating the upcoming load and its approaching time (By RSE with VRB). 5. Getting the Load on the previous traffic light (LTFP). 6. Getting the Load on the next traffic light (LTFN). 7. Detecting people aiming to cross the street. C. Load Calculation Stage. 2 Late Stage III. DYNAMIC TRAFFIC-LIGHT PHASE PLAN PROTOCOL (DT3P) 1 Early Stage C. Queue Length Determination To determine how long the vehicles queue on a road, is a major part of the congestion problem solution. Several studies have looked for methods to do the queue length determination, for instance, [4], [6], [8], [20], [9] ,[11], [12], and [13]. All of them have used Cameras to detect the queue length which is, as described before, will fail with foggy, heavy raining weather and in dark roads. Figure 3. DT3P stages If the answer is "No", then the vehicle would reply with a Half-Hello unicast message (MtAB) to the RSE. While if the answer was "Yes", then the vehicle would reply with a FullHello message (MtAC). As a part of vehicle identification, if an RSE detects a special vehicle entering the road and if its On- Duty Flag was ON, then immediately the RSE would send MtAG (Emergency Case Existence Alert) to the last RSE on the road declaring the special vehicle priority (LP) and whether the special vehicle on duty or not (LD). 4. Detecting people aiming to cross the street. this factor would be considered as an obstacle for the traffic light work. Figure 5. Late RDC Stage messaging Figure 4. Early RDC Stage messaging B. Late RDC Stage In the late RDC stage, four operations would be running in parallel, see Figure 5: 1. Estimating the upcoming load and its approaching time (By RSE with VRB). This operation starts when a vehicle (ΔAx) enters the coverage of the RSE (ΓAx) that is connected to the load estimation road belt and sends a Full-Hello (MtAC) reply to that RSE, confirming that it is on that specific road. The RSE would add a record for the car in its database. That record includes all the fixed and instant data of the vehicle in addition to the time stamp when the reply was received from the vehicle. From the recorded speed of the car, the RSE would calculate and estimate the time of arrival to the Road belt. A count down counter would be initiated for that vehicle starting from the calculated time. if the vehicle does not step over the belt within the count down, then a unicast Hello Message (MtAE) would be sent to the vehicle asking to report back. if the vehicle received the MtAE, then it would reply with a message type MtAF to the RSE when a new down counter would be initiated for that vehicle. While if the vehicle steps over the belt before the counter reaches zero, then vehicle arrival confirmation (MtAD) would be sent to the last RSE (ΓAL). The last RSE in turn, counts up the Total Confirmed Load (LCT). 2. Getting the Load on the previous traffic light (LTFP). By getting the vehicles load on the previous traffic light, we would add some kind of cooperation between the current traffic light and the one behind. the value of LTFP would be carried on a unicast message MtAK from the last RSE on the previous road (ΓZL) to the last RSE of the current road (ΓAL). 3. Getting the Load on the next traffic light (LTFN). This would add a cooperation feature among the traffic lights in a city without a central control. The LTFN value would carried within MtAJ message unicasted from the first RSE on the next road (ΓB1) to the last RSE on the current road (ΓAL). iii. Load Calculation Stage The last RSE on a road, repeatedly, calculate the total load of each lane on its road after it gets the six variable determined values from the early and the late stages. The parameter LW (Red Light Waiting Time) is to be managed by the last RSE. Additionally, when the last RSE setup, some variables would be configured with static values, such as: LC_Max (Maximum Load can be confirmed) and LNNR_Max (The Maximum Number of Vehicles the Next Road can take). LC% = (LCT / LC_Max) * 100% (1) LTFN% = (LTFN / LNNR_Max) * 100% (2) Load = LN * LC% * (LW + (LP * LD ) + LTFB ) * ( 100% – LTFN%) (3) Eventually, the calculated load of each lane would be sent to the TLC for the new phase decision making. D. Decision Making Stage The final stage of the protocol is to compare the load values came from the last RSEs to the TLC on that intersection to make two decisions; those are optimum phase sequence and Optimum green light timing for each lane. While a green phase being implemented, a comparison would take place among all the lanes (Lane X) load values (Loadx) with their crossing lanes load values (in a four leg intersection, there would be four crossing lanes for each lane) Loady1, Loady2, Loady3, Loady4. The main objective of this comparison is to sort the loads in descend order and decide how much extra time to add to lane X original time or to share with the more loaded crossing lane. Comp1 = Loadx - Loady1 Comp2 = Loadx - Loady2 Comp3 = Loadx - Loady3 Comp4 = Loadx - Loady4 (4) (5) (6) (7) The comparison would results 4 values. The result values would be either a positive value of a negative. If it was positive, that means the Lane X needs more time than the basic green time specified for it (usually it's 30 seconds). While if the comparison results was negative, then that crossing lane needs extra time. Among the four values, the least value would be taken and considered as the partner lane to share time with, as illustrated below: Total_LN = LNx + LNy (8) Total_Waiting_Time = WT x + WTy (9) New_Timex = Total_Waiting_Time * (LNx / Total_LN) (10) New_Timey = Total_Waiting_Time * (LNy / Total_LN) (11) small number of vehicles need to sacrifice their time to a bigger group of vehicles who are in need for it to achieve a better intersection performance. Accordingly, another comparison would happen between all the lanes load values to choose the two most loaded and compatible lanes to be green next phase. Finally, after the current green phase time is out, the new phase sequence with the new timing plan would be implemented. Figure 6. Intersection Average waiting time at Red Traffic Light IV. RESULTS AND DISCUSSION Using our customized Traffic Simulator, around 210 experiments were held to compare the efficiency of the proposed DT3P protocol with two existing strategies; Fixed-Time-Fixedcycle strategy and Actuated-Traffic-Light Strategy. Fixed-Time-Fixed-Cycle (FTFC) assumes fixed predetermined values of time split, cycle time and phase sequence. This strategy assigns 30 seconds for each traffic light as the split time, 120 seconds as the full cycle time, Minimum green time was set as 6 seconds and a fixed phasing sequence to be followed. The Actuated-Traffic-Light strategy is basically follows the same phasing sequence in FTFC, the Maximum cycle-time is 120 seconds, Minimum green time is 6 seconds (with an exception) and the maximum Split-Time is 30 seconds. But there are two features were added to the FTFC. The first is the Split time can be terminated if there is no vehicles on the road and move to the next phasing stage. While the second added feature is a stage can be skipped (No Minimum Green Time to be applied) if the phasing sequence comes to a stage which has no vehicles at its queue. The proposed DT3P suggests to determine the Split-Time, Cycle-Time, and the Phase sequence according to real time collected data. DT3P keeps the consideration for the minimum Green time as 6 seconds. A fixed value for the Maximum Green time was set as 45 Seconds to prevent very long waiting time. After simulating the three above strategies, it was found that intersection performance would be increased when using DT3P. In Figure 6, The X-axis of the following figure represents the experiments number. Each experiment was repeated three times, with the same lanes input volume conditions, using three different strategies. By looking to the three curves, we can see three curves illustrating the average vehicles waiting time at red traffic lights of the three strategies. When the queue length is short, as in the first 13 experiments, the vehicles do not need to wait for long time. This is why we can see the curve of DT3P underneath the other curves. As the queues start built up, some In terms of the Queue length at traffic light, the results shown in Figure 7 tell that the DT3P could bring down the queue lengths in almost all of the experiments. Figure 7. Average Vehicles Queue Length at Intersection Amber Time can be considered as wasted time. when an intersection gets loaded with less vehicles, it does not need a lot of time to release its load. That is why, by looking to the DT3P curve in Fig.17, during the first 14 experiments a lot of time was spent as Amber-Light-Time which will not be considered as waste as long as the intersection has released all of its load. While starting by experiment#15, the DT3P curve takes the bottom levels of the chart telling that applying DT3P on intersection would reduce the wasted time to its minimum levels Figure 8. Total Amber-Light-Time Spent During One Hour at Intersection V. CONCLUSION By setting up the proposed system architecture on road and applying the DT3P protocol at intersections, better intersection performance would be expected. Even though, the simulated performance of the three strategies shows that DT3P performance ( in terms of the intersection capacity) is almost the same as the others till experiment#13, but its performances in terms of the other factors are better. Measuring The Dynamic State Of Traffic", USA, Matsushita Electric Industrial Co., Ltd. [9] Jianzhong Huang, D. A. F. F. (2001), "System And Method For Detecting And Analyzing A Queue", USA, NCR Corporation. [10] LEE, Y.-S. (2002), "Control System To Prevent Lane Deviation Of Vehicle And Control Method Thereof", USA. REFERENCES Schroth, Christoph ; Strassberger, Markus ; Eigner, Robert ; Eichler, Stephan (2006), "A Framework for Network Utility Maximization in VANETs", Proceedings of the 3rd ACM International Workshop on Vehicular Ad Hoc Networks (VANET), Los Angeles, USA, p. 2 [11] Masakatsu Higashikubo, Y. I. (2001), "Traffic Congestion Measuring Method And Apparatus And Image Processing Method And Apparatus", USA, Sumitomo Electric Industries, Ltd. [12] Joon Suk Jun, S. H. C. (2003), "Apparatus And Method For Measuring Queue Length Of Vehicles", USA, LG Industrial Systems Co., Ltd. [2] Michael Cops, Program Manager, Vehicle Infrastructure Integration Consortium, VII Strategy for Safety and Mobility Program, Sept 29 2006. [13] Lee, H. C., Hsi-Che Lee, Tung-Hsing Pan, MeiJiuan Chen, (2004), "Traffic Light Control And Information Transmission Device", USA. [3] Book “Vehicular Networks: From Theory to Practice”, “NOTICE – An Architecture for Traffic incident Detection”, Stephan Olariu, Michele C. Weigle, 2009. [14] [4] A. G. Sims, K. W. D. (1980). "The Sydney Coordinated Adaptive Traffic (Scat) System Philosophy And Benifits." IEEE Transaction On Vehicular Technology, Vol. vt-29(No. 2): 8. Qing Li, N. Z., Hong Cheng (2004), "Springrobot A Prototype Autonomous Vehicle and Its Algorithms for Lane Detection." IEEE Transaction On Intelligent Transportation Systems Vol. 5, (No. 4, December 2004). [15] MARCY, R. (1983), "Apparatus for monitoring road traffic to control an associated signaling system", USA, THOMSON-CSF. Makoto Kimura, K. N. (2006), "On-Vehicle Navigation Apparatus Turnoff Road Guiding Method, Driving Lane Specifying Device, and Driving Lane Specifying Method", USA. [16] Arnold, J. (2002). "Traffic Guidance System", USA, Mitsubishi International GMBH. [17] Hongbin Yin, S. C. W., Jianmin Xu, C.K. Wong (2002), "Urban Traffic Flow Prediction Using A Fuzzy-Neural Approach" Elsevier - Pergamon Transportation Research Part C-10 (10 (2002) 8598): 85-98. [18] Rahman, M. R. (2002), "Method For Controlling Traffic", USA, Intel Corporation. [1] [5] [6] SUMNER, R. L. (1993), "Cell messaging process for an in-vehicle traffic congestion information system", USA, FARRADYNE SYSTEMS, INC. [7] DONG HOON KWAK, Y. S. O. (2002), "Method and apparatus for vehicle navigation service using DSRC system", USA. Masakazu Toyama, N. H. (1994), "Apparatus For [8]