# An Efficient Traffic Congestion Monitoring System on Internet of Vehicles

Authors: Duc-Binh Nguyen; Chyi-Ren Dow; Shiow-Fen Hwang
Journal: Wireless Communications and Mobile Computing
 (2018)

---

## Abstract

Existing intelligent transport systems (ITS) do not fully consider and resolve accuracy, instantaneity, and compatibility challenges while resolving traffic congestion in Internet of Vehicles (IoV) environments. This paper proposes a traffic congestion monitoring system, which includes data collection, segmented structure establishment, traffic-flow modelling, local segment traffic congestion prediction, and origin-destination traffic congestion service for drivers. Macroscopic model-based traffic-flow factors were formalized on the basis of the analysis results. Fuzzy rules-based local segment traffic congestion prediction was performed to determine the traffic congestion state. To enhance prediction efficiency, this paper presents a verification process for minimizing false predictions which is based on the Rankine-Hugoniot condition and an origin-destination traffic congestion service is also provided. To verify the feasibility of the proposed system, a prototype was implemented. The experimental results demonstrate that the proposed scheme can effectively monitor traffic congestion in terms of accuracy and system response time.


---

## Body

## 1. Introduction

Over the last few decades, traffic congestion has become a serious problem in cities, which not only negatively affects the daily lives of humans but also impedes stable economic and societal development. Traffic congestion increases air pollution, travel time, and economic losses. Governments increasingly strive to monitor and resolve traffic congestion, but the task is difficult because of the complexity of the problem; specifically, traffic congestion is difficult to predict. The complexity of traffic congestion is also reflected in its dynamic and interrelated characteristics. Traffic congestion can propagate from a congested road segment to neighboring road segments. Because of these complexities, fully automatic analysis of traffic congestion is difficult to achieve.Currently, two major challenges must be addressed to facilitate traffic congestion estimation and monitoring. The first challenge is formalizing the basic factors for estimating and forecasting traffic congestion on a large-scale road network. Several researchers have proposed solutions to resolve the problem, which can be grouped into two approaches, namely, traffic congestion forecasting based on infrastructure equipment and traffic congestion forecasting based on Vehicular Ad Hoc Network (VANET) technology. The first approach [1] mainly uses floating car data, namely, data from Global Positioning System- (GPS-) equipped vehicles. Some protocols use data from sensor equipment with the limitation, including loop detectors, video recording devices, and infrared technologies. Although the infrastructure-based approach is the most widespread and features high reliability and accurate formalization, it lacks flexibility. The second approach [2] utilizes vehicle-to-vehicle (V2V) technologies to gather vehicles’ traffic data and then formalizes the traffic model characteristics, including speed, density, flow, and travel time. Based on the formalized information, researchers have adopted mathematical prediction algorithms to estimate traffic congestion levels. The advantage to this approach is that it can be implemented without deploying infrastructure sensors and has been demonstrated to operate effectively in various traffic and deployment scenarios. However, the approach is limited by network communication obstacles, including delayed and inaccurate traffic estimates [3], redundant data, bandwidth problems [4], and reliability problems [5]. These problems may cause insufficient precision or even failure in traffic congestion prediction.The second challenge is to guarantee the accuracy, instantaneity, and reliability of traffic congestion prediction. Existing systems do not fully address and resolve this challenge. The VANET-based approach involves considerable propagation delays and low reliability, whereas the infrastructure-based approach generally uses GPS data and data from limited number of sensors that lack flexibility. Furthermore, most applications of the infrastructure-equipped approach use HTTP-based protocols for gathering and transferring data between a central computing unit and vehicles and equipment. This not only hinders integration with various types of sensor equipment but may also cause a serious overhead problem if the vehicle number increases markedly in a traffic congestion situation or if the amount of data transferred over a long period of time increases substantially. In contrast, because of the complexities of traffic congestion problems, these systems’ mechanisms simply classify traffic congestion levels by analyzing the traffic information on the basis of their own rules without verifying the real-time traffic conditions. This may result in false prediction [6].Considering the aforementioned problems, this paper proposes a traffic congestion monitoring system using real traffic data based on Message Queue Telemetry Transport (MQTT) for investigating traffic congestion patterns; the proposed system has the advantages of both an infrastructure-based approach and MQTT techniques: the flexibility to support the integration of various types of sensors for traffic-flow observation in low-bandwidth and high-latency vehicular network environments of MQTT and the high reliability and accurate traffic-flow formalization of an infrastructure-based approach. This research also adopted a fuzzy rule-based method to address complex nondeterministic problems such as traffic congestion determination. Furthermore, the proposed system is designed as a distributed system to eliminate computational bottlenecks and to avoid overhead problems, which is especially suitable for traffic congestion situations in which numerous communications are required due to the markedly increased number of vehicles. First, the authors formalized vehicle detector (VD) data provided by Taiwan’s government according to a macroscopic traffic-flow model. To provide a road segment-based traffic congestion monitoring service, the geographic map was converted to a segmented structure. Subsequently, the authors established a publish/subscribe platform using the MQTT protocol. Then, the authors defined the traffic congestion monitoring method and designed a mechanism that uses the segmented structure to predict local traffic congestion. The authors also designed and developed a real-time origin-destination traffic congestion service by using MQTT’s publish/subscribe feature. Finally, to verify the proposed system’s feasibility, the authors implemented a system prototype for both the control center and vehicles to evaluate user interfaces and communications and the system’s performance.The remainder of this paper is organized as follows. Section2 briefly describes the current relevant research and technology. Section 3 discusses the proposed traffic congestion monitoring method in detail. Section 4 details the implementation prototype. In Section 5, the experimental results are demonstrated. Finally, Section 6 presents conclusions and future research directions.


## 2. Related Work

The Internet of Things (IoT) era has opened up as an emerging research trend over recent years. The IoT has originated from the needs of better monitoring, control, and management in various areas, such as healthcare, education, entertainment, energy manager [7], and transportation [8]. The IoV plays as a part of the IoT, but it has distinctive characteristics. In the IoV, the mobility of vehicles is an important topic that needs to be paid attention. The IoV involves the way to gather information regarding sensors [9] on vehicles, roads, and their surroundings onto mobility platforms with the integration of the Internet. Based on collected information, IoV systems can effectively support vehicles by providing numerous services, including entertaining, guiding, surveillance, and protecting from unattended collision. IoV technologies aim to use in intelligent transportation systems (ITS) which deliver intelligent traffic applications as the typical IoT applications in mobility environment. In recent years, the IoV is proposed to provide more convenient services. Yang et al. [10] proposed an abstract IoV network model, which considers various connections of vehicles, roads, environments, and pedestrians. Fu et al. [11] present an effective way to solve the parking problem based on the reservation optimization parking recommendation model in the IoV environment. The model adopts a phased approach to actively recommend to drivers by means of interacting with the considering of evaluation indicators.With the development trend of the IoV, a huge number of sensors and vehicles tend to continuously connect to the Internet which may constitute the network bandwidth challenge. Due to this reason, it is necessary to develop suitable lightweight protocols for using in IoT/IoV environments. MQTT is one of the best developed candidates for this purpose. MQTT uses publish/subscribe model to get the polling information, and thus it can eliminate unnecessary communications that helps to save the energy consumption and lowers the delay for communication in vehicle environment compared to HTTP. Yokotani and Sasaki [12] proved that the MQTT protocol is more scalable and reliable for applications, which requires very high data transmission frequency as in IoV environments. In a deeper research, Del Campo et al. [13] presented an integrated different-degrees MQTT protocol architecture, which has an ability of effective and reliable distribution of notification messages among different actors. The proposed architecture has been adopted for the home monitoring of patients with dementia. Szabó and Farkas [14] presented a design for smart city application using MQTT publish/subscribe model for communication functions. The design aims to apply to crowd-sourcing based smart applications, such as smart travel planner or smart parking in the cities.Traffic congestion deals with negative impacts to people’s lives. Numerous research studies have highlighted the effect of traffic congestion, such as decreasing productivity and worsening pollution and increasing the transportation cost [15]. The traffic congestion effect can be seen in any country no matter it is a developing country or developed country. Traffic congestion is classified into two categories [16]: recurrent and nonrecurrent. Recurrent traffic congestion is a frequent basis type caused by various factors such as dramatic increases of traffic flow during peak hour [17] or repeated on-ramp and off-ramp road network [18]. Nonrecurrent congestion is an irregular type, which may happen due to road network disruptions such as road accidents and natural disaster [19]. To tackle with the traffic congestion problems, various scenarios have been proposed, which depended on various traffic flow detection techniques. Gholve and Chougule [20] proposed a wireless sensor network-based traffic congestion detection system for highways, which has developed a protocol to guarantee the communication between sensor nodes and was prototyped on an Arduino embedded device. The proposed system used magnetic sensors for vehicle detection through proper signal conditioning and use of data processing. Bhoraskar et al. [21] adopted probe vehicle-based techniques in cooperation with using of nonintrusive method to detect traffic congestion in Mumbai’s road network. The proposed system archived promising results in using smart phones sensors for traffic congestion detection.


## 3. Traffic Congestion Monitoring Scheme

In this section, the authors present the proposed traffic congestion monitoring scheme, particularly VD data collection, traffic-flow modelling, segmented structure establishment, publish/subscribe mechanism according to time and location, local segment traffic congestion prediction, and the origin-destination traffic congestion service for drivers.


### 3.1. Data Collection

Real data collection and analysis are vital requirements for forming a realistic system. In this subsection, the authors describe the collection of VD data and real-time vehicular data. The collected data are used to formalize fundamental factors according to macroscopic traffic-flow models, establish a segmented structure, and predict traffic congestion.


#### 3.1.1. Vehicle Detector Data Collection

In this study, the authors used VD data to determine traffic conditions. VD data analysis was performed to formalize the fundamental factors according to the macroscopic traffic-flow model that and used to extract information about the distribution of traffic flows. Furthermore, at the beginning of system development, more than 184 million historical VD records concerning traffic on the main roads of Taichung City, Taiwan, were sorted in ascending order of the recorded time. Table1 illustrates the data fields.Table 1
Historical VD Data Fields.
Device ID Longitude, latitude Date time Lane order Vehicle volume Average speed Max speed Travel directionThe device ID is a number unique to each VD device used to identify which device is recording. Longitude and latitude field indicates the location of the VD device. Longitude and latitude are also used to identify the road segment. For roads with more than one lane, lane order is the order number of the lane for which the traffic information has been obtained, and each record represents one lane of the road segment. The date-time field is used to store the time stamp of the recorded traffic event. Historical VD records represent traffic events and were obtained at 5-minute intervals. The vehicle volume field indicates the number of vehicles occupying the current lane of the road segment. The average speed field indicates the average speed of vehicles, which was measured using the VD devices. Speed limit is used to define the maximum allowable speed of the road lane. Travel direction is used to determine lanes whose travel direction is the same.


#### 3.1.2. Real-Time Vehicular Data Collection

The insufficiency of just-in-time information is a major cause of traffic congestion. In this study, to manage traffic congestion problems, real-time movement-related vehicular data are focused. In this system, the authors presume that vehicles play two roles. The first role, vehicles act as normal users that can subscribe to published topics to receive traffic congestion information using the MQTT model. In fact, each vehicle has a distinct origin-destination route. Thus, the proposed system provides vehicles the initiative in their origin-destination traffic congestion information. To handle origin-destination traffic congestion matter, each vehicle maintains a status table as shown in Table2.Table 2
Real-time vehicle’s data fields.
Vehicle ID Destination Longitude, latitude Date time SpeedThe vehicular ID is the unique vehicle registration plate number. The destination indicates the desired destination of predefined route. Longitude and latitude are used to identify the current road segment where the vehicle is located. The date-time field is used to determine the time when the record was recorded. The speed is the vehicle’s current speed, which, in combination with vehicle location, is used for origin-destination traffic congestion service.A vehicle acts the second role when the vehicle is selected as the header of a segment with a high possibility of congestion to publish information to MQTT topics. Each header is assigned to estimate traffic-flow and predict local traffic within its road segment. This design intends to eliminate communication redundancy and computational bottlenecks. Consequently, the overall performance and computational ability of the system should be improved. In the proposed system, the header vehicles and sensors possess a predefined identification number that helps the control center determine them in advance. Then, the control center can collect the header vehicles’ data following the topic structureDataColection/SourceID.


### 3.2. Segmented Structure

In fact, each segment of a road network exhibits different traffic-flow levels, and traffic congestion usually occurs in high-traffic-flow road segments. Traffic congestion starts at a specified road segment when the vehicle number reaches the capacity of the road segment. Thereafter, traffic congestion may propagate from a congested road segment to neighboring road segments. Because of this characteristic, the authors used historical VD data to investigate road network traffic-flow levels, which benefits local traffic congestion prediction. First, the authors used longitude and latitude information to locate VD devices on a geographical map as shown in Figure1(a). Each VD device is denoted by a red legend as the location symbol. Based on the recommendation of Taiwan’s government and to avoid redundant data in traffic observation, as well as wasted deployment and maintenance costs, a VD device should be recommended to be placed at a suitable location to guarantee that each VD device observes traffic flows on its own predefined road.Figure 1
VD based segmentation.
(a) (b)Subsequently, the authors divided the geographical map into segments as shown in Figure1(b). The authors assumed that N is the number of VD devices on a road; then, VD devices were ordered from 1 to N following the numbering rule of the road. Thus, the number of segments on each road depends on the number of VD devices. The determination of each segment of the road follows three rules. First, the first segment can be determined using the folloiwng:(1)startposVD1=xR0,yR0endposVD1=xR1,yR1∣distx1,y1,xR1,yR1=distxR1,yR1,x2,y2,where xR0,yR0 denotes the latitude and longitude coordinates of the start point of the road and x1,y1 and x2,y2 denote the latitude and longitude coordinates of VD1 and VD2, respectively.Second, the last segment can be determined using the following:(2)startposVDN=xRN-1,yRN-1∣distxN-1,yN-1,xRN-1,yRN-1=distxRN-1,yRN-1,xN,yNendposVDN=xRN,yRN,where xRN,yRN denotes the latitude and longitude coordinates of the last point of the road and xN-1,yN-1 and xN,yN denotes the latitude and longitude coordinates of VDN-1 and VDN, respectively. The last rule is used to determine VDi segments, where 1<i<N defines so-called normal segments. In the proposed system, a segment i where a VDi device is located can be calculated using the latitude and longitude of the VDi device and two neighboring VD devices. The formulas for segment determination can be expressed as follows:(3)startposVDi=xRi-1,yRi-1∣distxi-1,yi-1,xRi-1,yRi-1=distxRi-1,yRi-1,xi,yiendposVDi=xRi,yRi∣distxi,yi,xRi,yRi=distxRi,yRi,xi+1,yi+1,where xi,yi denotes the latitude and longitude coordinates of current VD device ordered as VDi and xi-1,yi-1 and xi+1,yi+1 denote the latitude and longitude coordinates of two neighboring VD devices ordered as VDi-1 and VDi+1.Finally, both the control center and vehicles can use MQTT publish/subscribe to exchange traffic congestion information in the model based on a segmented structure.


### 3.3. Traffic Flow Modelling

Traffic congestion problem management requires an explicit understanding of how traffic flow operates. Thus, many traffic-flow theories have been investigated over the last 60 years, and three types of traffic-flow models predominate, namely, microscopic, mesoscopic, and macroscopic [22]. Macroscopic models adopt a viewpoint of vehicular flow that is suited to large-scale network applications. Macroscopic models analyze three fundamental factors: velocity v (km/h), density d (vehicles/km), and flow f (vehicles/h). Velocity v=v(x,t) denotes the average velocity of vehicles on road segment x at time t. Density d=d(x,t) denotes the number of vehicles on road segment x at time t. Flow f=f(x,t) denotes the number of vehicles passing road segment x at time t. The relationship between flow, density, and velocity can be expressed as follows:(4)f=dvFor traffic flow factor calculation in this study, the authors used the real-time VD data that are shown in Table 1.The first factor of traffic flow, the velocity of a segment can be calculated as expressed in the following:(5)v=∑k=1mVelocityavglanekm,where v denotes the average velocity of the segment, Velocityavglanek is the average velocity in lane k, and m is the number of lanes with the same travel direction. Subsequently, the vehicle density is calculated as the number of vehicles per kilometer, which is expressed in the following:(6)d=∑k=1mVehiclevolumelanekl.The last factor, the flow reflects the number of vehicles passing through a road segment. On the basis of the relationship between density, velocity, and flow, as expressed in (4), the flow is calculated as shown in the following:(7)f=∑k=1mVelocityavglanek∗Vehiclevolumelanekl.


### 3.4. Local Segment Traffic Congestion Prediction

In this section, the authors provide a solution for local traffic congestion or road segment-based traffic congestion. First, the authors analyzed historical VD data to construct an observation table, which is used to identify road segments at a high risk of traffic congestion during specific hours of the day and on specific days of the week. Then, the authors evaluated the current traffic congestion situation of these road segments by using a fuzzy rule-based method on the basis of velocity and density. Finally, the authors performed a verification process, which involved using the remaining flow factors of these road segments and their neighboring road segments.


#### 3.4.1. Traffic Congestion Observation Table

To identify road segments at a high risk of traffic congestion and provide a global view of traffic transition, the authors used historical VD data for traffic analysis to build a traffic congestion observation table. In the past, density and velocity characteristics were used in a simple combination of their value range to determine the traffic congestion condition. For example, traffic congestion is identified in a road, which has a high vehicle density and a low velocity value. However, this strategy has limitations attributable to range value classification, because the range values of density and velocity vary greatly from road to road. This may cause inaccurate estimation and failure in traffic congestion prediction. Because of this problem, the authors propose the traffic congestion coefficient (TCC) concept, which represents the possibility of a traffic congestion condition existing on a large-scale road network. The TCC is calculated as shown in the following:(8)TCC=IdIvIND=dDmaxINV=vVmax,if  all  lanes  have  the  sameVmax∑k=1mVelocityavglanek/VMaxlanekm,if  each  lane  have  a  differentVmax,whereId is the density performance index;Iv is the velocity performance index;d is the average density of the road segment;v is the average velocity of the road segment;Vmax is the maximum limitation velocity of road segment;Dmax is the maximum recorded density in the road segment;Velocityavglanek is the average velocity of lane k in the road segment;VMaxlanek is the maximum limitation velocity of lane k in the road segment;l is the road segment length;m is the number of lanes which have the same travel direction.Because VD data records are extremely numerous, the records should be effectively analyzed to derive useful information. Thus, the authors divided historical VD records into seven sets, one for each day of the week, and then divided each set into 24 subsets, one for each hour of the day. Once the historical VD data records had been classified, the congestion coefficient value of segments in each set was calculated. The following assumptions are defined to explain the calculation efficiently:1.
W={Mon,Tue,Wed,Thu,Fri,Sat,Sun} indicates the day of the week of investigation.2.
TI={(0-1),(1-2),…,(23-24)} indicates the time interval of investigation.3.
TD={td0,td1} indicates the travel direction.4.
Rij={r1,r2,…,ru} indicates a set of historical VD records on day of the week i∈W and in time slot j∈TI.5.
RID={rid1,rid2,…,ridn} indicates the set of road segment IDs.6.
TCCijrid(td) indicates the TCC of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.7.
INDijrid(td) indicates the density performance index of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.8.
INVijrid(td) indicates the velocity performance index of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.9.
Dmaxrid(td) indicates the maximum recorded density of road segmentrid.10.
Nijrid(td) indicates the number of historical TCCs of road segmentrid on day of the week i∈W and in time slot j∈T.The following TCC calculation algorithm should be executed at the end of the day of the weeki and time slot j as shown in Algorithm 1.1.
(Lines(1)–(4)) First, INDijrid(td), INVijrid(td), Dijrid(td), and counterrid(td) variables, which are used for TCC calculation for each road segment on day of the week i and in time slot j are initialized. INDijrid(td) represents the density performance index value; INVijrid(td) represents the velocity performance index value; Dijrid(td) represents the density value; counterrid(td) denotes the number of records for each day of the week i and time slot j. At the beginning, variable values are assigned as zero or NULL.2.
(Lines(5)–(11)) Second, each historical VD data record is investigated to extract the speed and volume information of vehicles. The information is classified by road segment. The calculation results are temporarily expressed as the INVijrid(td) and Dijrid(td) variables of each road segment.3.
(Lines(12)–(15)) Third, the previous values of TCC, number of TCC calculation, and max density are read for TCC calculation.4.
(Lines(16)–(19)) To improve the accuracy of density performance index calculation, the estimated density value of the current session is evaluated by comparing it with the maximum density. If the current density value is greater than the maximum density value, the maximum density value is updated as the current density value.5.
(Lines(20)–(22)) Subsequently, the TCC of each road segment in time slot j and day of the week i is calculated on the basis of (8), (12), and (13), which considers both current session data and previous session data.6.
(Lines(23)–(26)) Finally, the calculated TCC value and the number of TCC calculation session of each road segment are stored in the database for the next TCC calculation session.Algorithm 1:Pseudocode of TCC calculation algorithm.
TCC Calculation Algorithm (1) INDijrid(td)=0 (2) INVijrid(td)=0 (3) Dijrid(td)=0 (4) counterrid(td)=0 (5) Foreach rk∈Rijdo (6)  Ifrk.device_id = ridp and rk.travel_direction=tdqthen (7)      INVijridp(tdq)=INVijridp(tdq)+rk.Vavgrk.VMax (8)      Dijridp(tdq)=Dijridp(tdq)+rk.Vehicle_volumeLengthridp (9)      counterridp(tdq)=counterridp(tdq)+1 (10)  End if (11)  End for (12) Foreach traveling direction tdq∈TD of ridp∈RIDdo (13)  Read (TCCijridptdq) (14)  Read (Nijridptdq) (15)  Read (DijMaxridptdq) (16)  If(Dijridp(tdq)∗ridp.number_of_lanes)/counterridp(tdq)>DijMaxridp(tdq)then (17)DijMaxridp(tdq)⟵Dijridp(tdq)∗ridp.number_of_lanescounterridp(tdq) (18)     Write(DijMaxridptdq) (19)End if (20)INVijridp(tdq)=INVijridp(tdq)counterridp(tdq) (21)INDijridp(tdq)=Dijridp(tdq)∗ridp.number_of_lanescounterridp(tdq)∗DijMaxridp(tdq) (22)TCCijridp(tdq)=TCCijridp(tdq)∗Nijridptdq+INDijridp(tdq)/INVijridp(tdq)Nijridp(tdq)+1 (23)Nijridk=Nijridk+1 (24)  Write(TCCijridptdq) (25)  Write(TCCijridptdq) (26)End forThe calculation results are maintained as tables in the control center; each table corresponds to a set of historical VD data as illustrated in Table3. Furthermore, to quantify the TCC values, the authors define two types of road segments on the basis of their correlated range of TCC values: first, a road segment with a high possibility of traffic congestion has a TCC value greater than 1; second, a road segment with a low possibility of traffic congestion has a TCC value equal to or lower than 1. The first type has a high possibility of traffic congestion, whereas the second type is almost traffic congestion free. If a road segment’s TCC value equals 1, its density and velocity correlate sufficiently to guarantee stable traffic conditions on the road.Table 3
Traffic congestion observation table.
Day of week Time interval Segment ID Location Congestion coefficient value Sat. (17-18) V069320 (24.145285, 120.632205) 1.25 Sat. (17-18) V029500 (24.17083, 120.685352) 0.8


#### 3.4.2. Fuzzy-Based Traffic Congestion Evaluation

Fuzzy rules-based methods are a particularly suitable solution for addressing complex nondeterministic problems, including transportation field [23]. In this paper, the authors propose a fuzzy logic-based traffic congestion evaluation method that uses the estimated traffic density and velocity performance index of a road segment as input parameters. The proposed method provides the results of traffic congestion level evaluation. The method is applied to road segments that are at a high risk of traffic congestion as determined using the traffic congestion observation table and from segments discovered to have traffic-flow values higher than usual. The following assumptions are defined to explain the algorithm.1.
RO={ro1,ro2,…,roz} denotes the set of records in the corresponding traffic congestion observation table of the evaluation.2.
UpdateIND denotes an updated density performance index value of a segment.3.
UpdateINV denotes an updated velocity performance index value of a segment.The following initiation algorithm should be executed to start fuzzy rule-based traffic congestion evaluation, as presented in Algorithm2.1.
(Lines(1)-(2)) First, the UpdateIND and UpdateINV, which are used to store updated density performance index value and velocity performance index value of a segment, are initialized. At the beginning, variable values are assigned as zero.2.
(Lines(3)–(6)) Second, each record of traffic congestion observation table is investigated to decide which segments need to be evaluated using fuzzy rules-based traffic congestion evaluation. If the current coefficient value is greater than 1, the fuzzy rules-based traffic congestion evaluation is activated on the corresponding segment of the record.3.
(Lines(7)–(15)) Third, if the current coefficient value is smaller than or equal to one, then the density performance index value UpdateIND and velocity performance index value UpdateINV of the corresponding segment will be updated. Under this circumstance, if division UpdateIND by UpdateINV is greater than current coefficient value, which may represent an abnormal traffic congestion situation. Subsequently, the fuzzy rules-based traffic congestion evaluation is required to perform on the corresponding segment of the record.Algorithm 2:Pseudocode of initiation algorithm of fuzzy-based traffic congestion evaluation.
Initiation Algorithm of Fuzzy-based Traffic Congestion Evaluation (1) UpdateIND=0 (2) UpdateINV=0 (3) Foreach rok∈ROdo (4)  Ifrok.congestion_coefficient_value > 1 then (5)   Evaluation(rok) (6)  End if (7)  Else (8)   UpdateINDrok=Get_update(rok,IND) (9)   UpdateINVrok=Get_update(rok,INV) (10)   IfUpdateINDrok/UpdateINVrok>rok.congestion_coefficient_valuethen (11)    Evaluation(rok) (12)   End if (13)   Else exit (14)  End else (15) End forThe control center selects the header for each road segment with a high possibility of traffic congestion. Normally, the vehicle that has remained for the longest in each road segment is selected as a header to maximize stability. For example, a bus that has spent the longest time in a particular road segment is selected as the grid header. In rare situations, in which no vehicle is equipped with an onboard smart device for header selection or most vehicles, including the selected header, tend to leave the segment in an extremely short time before the completion of traffic-flow estimation or local traffic prediction, the control center is assigned to finalize uncompleted tasks to guarantee stability. Consequently, each header subscribes to a VD data topic that is maintained by the control center to track real-time VD data. The real-time VD data are used to estimate the traffic density and velocity performance index of the road segment by using (12) and (13). The estimation results are published to the control center by using the MQTT publish method for maintaining traffic data topic and used as input variables for fuzzy rules-based traffic congestion evaluation.Traffic congestion situation is directly linked with high values of the density performance index. Consequently, the high category of the density performance index is divided into two further categories, high and very high. Thus, the input variables are divided into fuzzy categories: the fuzzy categories of the density performance index are very high, high, medium, and low. The fuzzy categories of the velocity performance index are low, medium, and high. The partial degrees of membership functions are defined as shown in Figure2. The output fuzzy categories reflect traffic congestion levels, which are assigned, according to Taichung City Government’s traffic congestion classification framework, into four categories: free flow, stable flow, unstable flow, and congested. The fuzzy rules are defined to evaluate output fuzzy categories on the basis of input fuzzy categories, which are shown in Table 4. Finally, the fuzzy rules-based traffic congestion condition is evaluated using the header.Table 4
Fuzzy rules for traffic congestion evaluation.
Velocity performance index Low Medium High Density performance index Low Stable flow Free-flow Free-flow Medium Unstable flow Stable flow Free-flow High Congested Unstable flow Stable flow Very High Congested Unstable flow Stable flowFigure 2
Velocity and density performance index membership function.


#### 3.4.3. Traffic Congestion Condition Verification

To minimize false predictions, the authors propose traffic congestion condition verification. Whereas traffic congestion predictions involve employing road segment traffic velocity and density characteristics to predict the traffic congestion condition, the traffic congestion verification process entails analyzing the close relationship between a road segment under investigation and neighboring road segments to verify the traffic congestion condition of the road segment.This relationship is used in traffic congestion verification because of the shock wave phenomenon, in which each road segment transfers traffic pressure to its neighboring. This phenomenon may cause traffic congestion on neighboring road segments and was first mentioned by Franklin [24]. A shock wave is a type of kinematic wave. A shock wave occurs when two continuous road segments r1 and r2 encounter density shock (dr>0, where dr=dr2-dr1). The velocity Vs of the shock wave can be obtained using theRankine-Hugoniot conditions [25], as shown in the following:(9)Vs=frdr=fr2-fr1dr2-dr1.Obviously, the direction awareness of Vs depends on the sign of the result of subtracting outflow traffic fr2 from inflow traffic fr1, since outflow traffic fr2 being less than inflow traffic fr1 implies an upstream moving shock (Vs<0), which directly indicates a congested [22].On this basis, the proposed traffic congestion verification proceeds as follows. When a road segment experiences a congestion condition as defined using the fuzzy rules-based method, traffic congestion verification is triggered by the control center. The control center thereafter maintains a traffic-flow topic for each road segment as illustrated in Figure3, which allows the system to store information on traffic flow and traffic direction for each road segment. Meanwhile, the control center maintains an inflow neighbor table for each road segment for managing inflow, as illustrated in Table 5. The content of the inflow neighbor table is derived from corresponding traffic-flow tables. Using the inflow neighbor table of a particular road segment, the control center selects a header in each road segment. Each header is thereafter responsible for traffic data estimation within its road segment. The headers periodically upload flow value and density value information for their road segments. Traffic data estimation follows (6) and (7). Once the traffic data of the road segments have been estimated, the verification process begins, during which the traffic data of road segments under investigation and inflow neighboring road segments, including flow and density values, are collected. The headers transmit the data to the control center for verification by using the MQTT publish method. Subsequently, using the data received from the headers of road segments under investigation and inflow neighboring road segments, the control center examines whether the data fulfil the Rankine-Hugoniot conditions. The Rankine-Hugoniot conditions are evaluated under this circumstance, as expressed in (10). A congested condition is confirmed when Vs<0.(10)Vs=frdr=frivs-∑frinfdrivs-∑drinf,where Vs is the shock wave velocity;fr is the flow shock;dr is the density shock;frivs is the outflow of the road segment under investigation;frinf is the inflow to the road segment under investigation from the inflow neighboring road segment;drivs is the density of the road segment under investigation;drinf is the inflow to the road segment under investigation from the inflow neighboring road segment.Table 5
Inflow neighbor table.
Segment ID Inflow neighborFigure 3
Traffic flows MQTT topic.The following assumptions are defined to explain the congestion verification process:1.
R={r1,r2,…} indicates a set of road segments.2.
G={g1,g2,…} indicates a set of grid headers.The algorithm used for traffic congestion verification is described as shown in Algorithm3.Algorithm 3:Pseudocode of traffic congestion condition verification.
Traffic Congestion Condition Verification Operation (1) If(Fuzzy_Based_Evaluation(rc) == ‘congested’) then (2)  Verfication_Result =NULL (3)  Foreach rido (4)   If(Exist_Outflow(lanej,rk) == true) then (5)   Update_Neighbor(rj) to inflow neighbor table of rk (6)   End if (7)  End For (8)  Foreach inflow neighbor rk of rcdo (9)   grk = Select_header(rk) (10)  End for (11)  While(Verfication_Result=NULL)do (12)   grc performs Update_traffic(flow, density) to traffic flow table of rc (13)   grc performs Publish(flow, density, rc) to the control center (14)   For each inflow neighbor rk of rcdo (15)     grk performs Update_traffic(flow, density) to traffic flow table of rk (16)     grk performs Publish(flow, density, rk) to the control center (17)End For (18)doRankine-Hugoniot_Validation(ri,rk1,rk2,…,rkn) (19)If (Rankine-Hugoniot_Validation(ri,rk1,rk2,…,rkn)<0)then (20)Verfication_Result== ‘Verified’ (21)ElseVerfication_Result==‘Failed’ (22)     Fuzzy_Based_Evaluation(rc) = ‘unstable-flow’ (23)End while (24)End if


### 3.5. Origin-Destination Traffic Congestion Service for Drivers

An origin-destination traffic congestion service is proposed to provide on-the-way congestion information for drivers who travel through road segments to their destination. The origin-destination traffic congestion service is used when a traffic congestion condition has been verified on a road segment and the preselected travel route of the vehicle traverses the verified road segment. The workflow of the proposed mechanism is detailed as follows: once a congested condition has been verified on a road segment, the control center establishes the segments order number as 1 to denote the road segment as a level 1 congestion road segment, creates an event ID for the congestion, and changes the road segment’s status to ‘congested.’ Vehicles on the inflow neighboring road segments are then informed of the congested status. Thereafter, each header of inflow neighboring road segments that are classified as level 2 congestion road segments updates the order value by increasing it by 1. This task is repeated sequentially for level three congestion road segments and so on. The task is completed when all interrelated inflow neighboring road segments have updated their congestion status. Once the process has been completed, each vehicle with a unique traveling route that directly passes through the verified congested segment will estimate origin-destination traffic congestion information based on the instant distance to the congested road segment and the velocity of the vehicle, as illustrated in Figure5.


## 3.1. Data Collection

Real data collection and analysis are vital requirements for forming a realistic system. In this subsection, the authors describe the collection of VD data and real-time vehicular data. The collected data are used to formalize fundamental factors according to macroscopic traffic-flow models, establish a segmented structure, and predict traffic congestion.


### 3.1.1. Vehicle Detector Data Collection

In this study, the authors used VD data to determine traffic conditions. VD data analysis was performed to formalize the fundamental factors according to the macroscopic traffic-flow model that and used to extract information about the distribution of traffic flows. Furthermore, at the beginning of system development, more than 184 million historical VD records concerning traffic on the main roads of Taichung City, Taiwan, were sorted in ascending order of the recorded time. Table1 illustrates the data fields.Table 1
Historical VD Data Fields.
Device ID Longitude, latitude Date time Lane order Vehicle volume Average speed Max speed Travel directionThe device ID is a number unique to each VD device used to identify which device is recording. Longitude and latitude field indicates the location of the VD device. Longitude and latitude are also used to identify the road segment. For roads with more than one lane, lane order is the order number of the lane for which the traffic information has been obtained, and each record represents one lane of the road segment. The date-time field is used to store the time stamp of the recorded traffic event. Historical VD records represent traffic events and were obtained at 5-minute intervals. The vehicle volume field indicates the number of vehicles occupying the current lane of the road segment. The average speed field indicates the average speed of vehicles, which was measured using the VD devices. Speed limit is used to define the maximum allowable speed of the road lane. Travel direction is used to determine lanes whose travel direction is the same.


### 3.1.2. Real-Time Vehicular Data Collection

The insufficiency of just-in-time information is a major cause of traffic congestion. In this study, to manage traffic congestion problems, real-time movement-related vehicular data are focused. In this system, the authors presume that vehicles play two roles. The first role, vehicles act as normal users that can subscribe to published topics to receive traffic congestion information using the MQTT model. In fact, each vehicle has a distinct origin-destination route. Thus, the proposed system provides vehicles the initiative in their origin-destination traffic congestion information. To handle origin-destination traffic congestion matter, each vehicle maintains a status table as shown in Table2.Table 2
Real-time vehicle’s data fields.
Vehicle ID Destination Longitude, latitude Date time SpeedThe vehicular ID is the unique vehicle registration plate number. The destination indicates the desired destination of predefined route. Longitude and latitude are used to identify the current road segment where the vehicle is located. The date-time field is used to determine the time when the record was recorded. The speed is the vehicle’s current speed, which, in combination with vehicle location, is used for origin-destination traffic congestion service.A vehicle acts the second role when the vehicle is selected as the header of a segment with a high possibility of congestion to publish information to MQTT topics. Each header is assigned to estimate traffic-flow and predict local traffic within its road segment. This design intends to eliminate communication redundancy and computational bottlenecks. Consequently, the overall performance and computational ability of the system should be improved. In the proposed system, the header vehicles and sensors possess a predefined identification number that helps the control center determine them in advance. Then, the control center can collect the header vehicles’ data following the topic structureDataColection/SourceID.


## 3.1.1. Vehicle Detector Data Collection

In this study, the authors used VD data to determine traffic conditions. VD data analysis was performed to formalize the fundamental factors according to the macroscopic traffic-flow model that and used to extract information about the distribution of traffic flows. Furthermore, at the beginning of system development, more than 184 million historical VD records concerning traffic on the main roads of Taichung City, Taiwan, were sorted in ascending order of the recorded time. Table1 illustrates the data fields.Table 1
Historical VD Data Fields.
Device ID Longitude, latitude Date time Lane order Vehicle volume Average speed Max speed Travel directionThe device ID is a number unique to each VD device used to identify which device is recording. Longitude and latitude field indicates the location of the VD device. Longitude and latitude are also used to identify the road segment. For roads with more than one lane, lane order is the order number of the lane for which the traffic information has been obtained, and each record represents one lane of the road segment. The date-time field is used to store the time stamp of the recorded traffic event. Historical VD records represent traffic events and were obtained at 5-minute intervals. The vehicle volume field indicates the number of vehicles occupying the current lane of the road segment. The average speed field indicates the average speed of vehicles, which was measured using the VD devices. Speed limit is used to define the maximum allowable speed of the road lane. Travel direction is used to determine lanes whose travel direction is the same.


## 3.1.2. Real-Time Vehicular Data Collection

The insufficiency of just-in-time information is a major cause of traffic congestion. In this study, to manage traffic congestion problems, real-time movement-related vehicular data are focused. In this system, the authors presume that vehicles play two roles. The first role, vehicles act as normal users that can subscribe to published topics to receive traffic congestion information using the MQTT model. In fact, each vehicle has a distinct origin-destination route. Thus, the proposed system provides vehicles the initiative in their origin-destination traffic congestion information. To handle origin-destination traffic congestion matter, each vehicle maintains a status table as shown in Table2.Table 2
Real-time vehicle’s data fields.
Vehicle ID Destination Longitude, latitude Date time SpeedThe vehicular ID is the unique vehicle registration plate number. The destination indicates the desired destination of predefined route. Longitude and latitude are used to identify the current road segment where the vehicle is located. The date-time field is used to determine the time when the record was recorded. The speed is the vehicle’s current speed, which, in combination with vehicle location, is used for origin-destination traffic congestion service.A vehicle acts the second role when the vehicle is selected as the header of a segment with a high possibility of congestion to publish information to MQTT topics. Each header is assigned to estimate traffic-flow and predict local traffic within its road segment. This design intends to eliminate communication redundancy and computational bottlenecks. Consequently, the overall performance and computational ability of the system should be improved. In the proposed system, the header vehicles and sensors possess a predefined identification number that helps the control center determine them in advance. Then, the control center can collect the header vehicles’ data following the topic structureDataColection/SourceID.


## 3.2. Segmented Structure

In fact, each segment of a road network exhibits different traffic-flow levels, and traffic congestion usually occurs in high-traffic-flow road segments. Traffic congestion starts at a specified road segment when the vehicle number reaches the capacity of the road segment. Thereafter, traffic congestion may propagate from a congested road segment to neighboring road segments. Because of this characteristic, the authors used historical VD data to investigate road network traffic-flow levels, which benefits local traffic congestion prediction. First, the authors used longitude and latitude information to locate VD devices on a geographical map as shown in Figure1(a). Each VD device is denoted by a red legend as the location symbol. Based on the recommendation of Taiwan’s government and to avoid redundant data in traffic observation, as well as wasted deployment and maintenance costs, a VD device should be recommended to be placed at a suitable location to guarantee that each VD device observes traffic flows on its own predefined road.Figure 1
VD based segmentation.
(a) (b)Subsequently, the authors divided the geographical map into segments as shown in Figure1(b). The authors assumed that N is the number of VD devices on a road; then, VD devices were ordered from 1 to N following the numbering rule of the road. Thus, the number of segments on each road depends on the number of VD devices. The determination of each segment of the road follows three rules. First, the first segment can be determined using the folloiwng:(1)startposVD1=xR0,yR0endposVD1=xR1,yR1∣distx1,y1,xR1,yR1=distxR1,yR1,x2,y2,where xR0,yR0 denotes the latitude and longitude coordinates of the start point of the road and x1,y1 and x2,y2 denote the latitude and longitude coordinates of VD1 and VD2, respectively.Second, the last segment can be determined using the following:(2)startposVDN=xRN-1,yRN-1∣distxN-1,yN-1,xRN-1,yRN-1=distxRN-1,yRN-1,xN,yNendposVDN=xRN,yRN,where xRN,yRN denotes the latitude and longitude coordinates of the last point of the road and xN-1,yN-1 and xN,yN denotes the latitude and longitude coordinates of VDN-1 and VDN, respectively. The last rule is used to determine VDi segments, where 1<i<N defines so-called normal segments. In the proposed system, a segment i where a VDi device is located can be calculated using the latitude and longitude of the VDi device and two neighboring VD devices. The formulas for segment determination can be expressed as follows:(3)startposVDi=xRi-1,yRi-1∣distxi-1,yi-1,xRi-1,yRi-1=distxRi-1,yRi-1,xi,yiendposVDi=xRi,yRi∣distxi,yi,xRi,yRi=distxRi,yRi,xi+1,yi+1,where xi,yi denotes the latitude and longitude coordinates of current VD device ordered as VDi and xi-1,yi-1 and xi+1,yi+1 denote the latitude and longitude coordinates of two neighboring VD devices ordered as VDi-1 and VDi+1.Finally, both the control center and vehicles can use MQTT publish/subscribe to exchange traffic congestion information in the model based on a segmented structure.


## 3.3. Traffic Flow Modelling

Traffic congestion problem management requires an explicit understanding of how traffic flow operates. Thus, many traffic-flow theories have been investigated over the last 60 years, and three types of traffic-flow models predominate, namely, microscopic, mesoscopic, and macroscopic [22]. Macroscopic models adopt a viewpoint of vehicular flow that is suited to large-scale network applications. Macroscopic models analyze three fundamental factors: velocity v (km/h), density d (vehicles/km), and flow f (vehicles/h). Velocity v=v(x,t) denotes the average velocity of vehicles on road segment x at time t. Density d=d(x,t) denotes the number of vehicles on road segment x at time t. Flow f=f(x,t) denotes the number of vehicles passing road segment x at time t. The relationship between flow, density, and velocity can be expressed as follows:(4)f=dvFor traffic flow factor calculation in this study, the authors used the real-time VD data that are shown in Table 1.The first factor of traffic flow, the velocity of a segment can be calculated as expressed in the following:(5)v=∑k=1mVelocityavglanekm,where v denotes the average velocity of the segment, Velocityavglanek is the average velocity in lane k, and m is the number of lanes with the same travel direction. Subsequently, the vehicle density is calculated as the number of vehicles per kilometer, which is expressed in the following:(6)d=∑k=1mVehiclevolumelanekl.The last factor, the flow reflects the number of vehicles passing through a road segment. On the basis of the relationship between density, velocity, and flow, as expressed in (4), the flow is calculated as shown in the following:(7)f=∑k=1mVelocityavglanek∗Vehiclevolumelanekl.


## 3.4. Local Segment Traffic Congestion Prediction

In this section, the authors provide a solution for local traffic congestion or road segment-based traffic congestion. First, the authors analyzed historical VD data to construct an observation table, which is used to identify road segments at a high risk of traffic congestion during specific hours of the day and on specific days of the week. Then, the authors evaluated the current traffic congestion situation of these road segments by using a fuzzy rule-based method on the basis of velocity and density. Finally, the authors performed a verification process, which involved using the remaining flow factors of these road segments and their neighboring road segments.


### 3.4.1. Traffic Congestion Observation Table

To identify road segments at a high risk of traffic congestion and provide a global view of traffic transition, the authors used historical VD data for traffic analysis to build a traffic congestion observation table. In the past, density and velocity characteristics were used in a simple combination of their value range to determine the traffic congestion condition. For example, traffic congestion is identified in a road, which has a high vehicle density and a low velocity value. However, this strategy has limitations attributable to range value classification, because the range values of density and velocity vary greatly from road to road. This may cause inaccurate estimation and failure in traffic congestion prediction. Because of this problem, the authors propose the traffic congestion coefficient (TCC) concept, which represents the possibility of a traffic congestion condition existing on a large-scale road network. The TCC is calculated as shown in the following:(8)TCC=IdIvIND=dDmaxINV=vVmax,if  all  lanes  have  the  sameVmax∑k=1mVelocityavglanek/VMaxlanekm,if  each  lane  have  a  differentVmax,whereId is the density performance index;Iv is the velocity performance index;d is the average density of the road segment;v is the average velocity of the road segment;Vmax is the maximum limitation velocity of road segment;Dmax is the maximum recorded density in the road segment;Velocityavglanek is the average velocity of lane k in the road segment;VMaxlanek is the maximum limitation velocity of lane k in the road segment;l is the road segment length;m is the number of lanes which have the same travel direction.Because VD data records are extremely numerous, the records should be effectively analyzed to derive useful information. Thus, the authors divided historical VD records into seven sets, one for each day of the week, and then divided each set into 24 subsets, one for each hour of the day. Once the historical VD data records had been classified, the congestion coefficient value of segments in each set was calculated. The following assumptions are defined to explain the calculation efficiently:1.
W={Mon,Tue,Wed,Thu,Fri,Sat,Sun} indicates the day of the week of investigation.2.
TI={(0-1),(1-2),…,(23-24)} indicates the time interval of investigation.3.
TD={td0,td1} indicates the travel direction.4.
Rij={r1,r2,…,ru} indicates a set of historical VD records on day of the week i∈W and in time slot j∈TI.5.
RID={rid1,rid2,…,ridn} indicates the set of road segment IDs.6.
TCCijrid(td) indicates the TCC of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.7.
INDijrid(td) indicates the density performance index of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.8.
INVijrid(td) indicates the velocity performance index of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.9.
Dmaxrid(td) indicates the maximum recorded density of road segmentrid.10.
Nijrid(td) indicates the number of historical TCCs of road segmentrid on day of the week i∈W and in time slot j∈T.The following TCC calculation algorithm should be executed at the end of the day of the weeki and time slot j as shown in Algorithm 1.1.
(Lines(1)–(4)) First, INDijrid(td), INVijrid(td), Dijrid(td), and counterrid(td) variables, which are used for TCC calculation for each road segment on day of the week i and in time slot j are initialized. INDijrid(td) represents the density performance index value; INVijrid(td) represents the velocity performance index value; Dijrid(td) represents the density value; counterrid(td) denotes the number of records for each day of the week i and time slot j. At the beginning, variable values are assigned as zero or NULL.2.
(Lines(5)–(11)) Second, each historical VD data record is investigated to extract the speed and volume information of vehicles. The information is classified by road segment. The calculation results are temporarily expressed as the INVijrid(td) and Dijrid(td) variables of each road segment.3.
(Lines(12)–(15)) Third, the previous values of TCC, number of TCC calculation, and max density are read for TCC calculation.4.
(Lines(16)–(19)) To improve the accuracy of density performance index calculation, the estimated density value of the current session is evaluated by comparing it with the maximum density. If the current density value is greater than the maximum density value, the maximum density value is updated as the current density value.5.
(Lines(20)–(22)) Subsequently, the TCC of each road segment in time slot j and day of the week i is calculated on the basis of (8), (12), and (13), which considers both current session data and previous session data.6.
(Lines(23)–(26)) Finally, the calculated TCC value and the number of TCC calculation session of each road segment are stored in the database for the next TCC calculation session.Algorithm 1:Pseudocode of TCC calculation algorithm.
TCC Calculation Algorithm (1) INDijrid(td)=0 (2) INVijrid(td)=0 (3) Dijrid(td)=0 (4) counterrid(td)=0 (5) Foreach rk∈Rijdo (6)  Ifrk.device_id = ridp and rk.travel_direction=tdqthen (7)      INVijridp(tdq)=INVijridp(tdq)+rk.Vavgrk.VMax (8)      Dijridp(tdq)=Dijridp(tdq)+rk.Vehicle_volumeLengthridp (9)      counterridp(tdq)=counterridp(tdq)+1 (10)  End if (11)  End for (12) Foreach traveling direction tdq∈TD of ridp∈RIDdo (13)  Read (TCCijridptdq) (14)  Read (Nijridptdq) (15)  Read (DijMaxridptdq) (16)  If(Dijridp(tdq)∗ridp.number_of_lanes)/counterridp(tdq)>DijMaxridp(tdq)then (17)DijMaxridp(tdq)⟵Dijridp(tdq)∗ridp.number_of_lanescounterridp(tdq) (18)     Write(DijMaxridptdq) (19)End if (20)INVijridp(tdq)=INVijridp(tdq)counterridp(tdq) (21)INDijridp(tdq)=Dijridp(tdq)∗ridp.number_of_lanescounterridp(tdq)∗DijMaxridp(tdq) (22)TCCijridp(tdq)=TCCijridp(tdq)∗Nijridptdq+INDijridp(tdq)/INVijridp(tdq)Nijridp(tdq)+1 (23)Nijridk=Nijridk+1 (24)  Write(TCCijridptdq) (25)  Write(TCCijridptdq) (26)End forThe calculation results are maintained as tables in the control center; each table corresponds to a set of historical VD data as illustrated in Table3. Furthermore, to quantify the TCC values, the authors define two types of road segments on the basis of their correlated range of TCC values: first, a road segment with a high possibility of traffic congestion has a TCC value greater than 1; second, a road segment with a low possibility of traffic congestion has a TCC value equal to or lower than 1. The first type has a high possibility of traffic congestion, whereas the second type is almost traffic congestion free. If a road segment’s TCC value equals 1, its density and velocity correlate sufficiently to guarantee stable traffic conditions on the road.Table 3
Traffic congestion observation table.
Day of week Time interval Segment ID Location Congestion coefficient value Sat. (17-18) V069320 (24.145285, 120.632205) 1.25 Sat. (17-18) V029500 (24.17083, 120.685352) 0.8


### 3.4.2. Fuzzy-Based Traffic Congestion Evaluation

Fuzzy rules-based methods are a particularly suitable solution for addressing complex nondeterministic problems, including transportation field [23]. In this paper, the authors propose a fuzzy logic-based traffic congestion evaluation method that uses the estimated traffic density and velocity performance index of a road segment as input parameters. The proposed method provides the results of traffic congestion level evaluation. The method is applied to road segments that are at a high risk of traffic congestion as determined using the traffic congestion observation table and from segments discovered to have traffic-flow values higher than usual. The following assumptions are defined to explain the algorithm.1.
RO={ro1,ro2,…,roz} denotes the set of records in the corresponding traffic congestion observation table of the evaluation.2.
UpdateIND denotes an updated density performance index value of a segment.3.
UpdateINV denotes an updated velocity performance index value of a segment.The following initiation algorithm should be executed to start fuzzy rule-based traffic congestion evaluation, as presented in Algorithm2.1.
(Lines(1)-(2)) First, the UpdateIND and UpdateINV, which are used to store updated density performance index value and velocity performance index value of a segment, are initialized. At the beginning, variable values are assigned as zero.2.
(Lines(3)–(6)) Second, each record of traffic congestion observation table is investigated to decide which segments need to be evaluated using fuzzy rules-based traffic congestion evaluation. If the current coefficient value is greater than 1, the fuzzy rules-based traffic congestion evaluation is activated on the corresponding segment of the record.3.
(Lines(7)–(15)) Third, if the current coefficient value is smaller than or equal to one, then the density performance index value UpdateIND and velocity performance index value UpdateINV of the corresponding segment will be updated. Under this circumstance, if division UpdateIND by UpdateINV is greater than current coefficient value, which may represent an abnormal traffic congestion situation. Subsequently, the fuzzy rules-based traffic congestion evaluation is required to perform on the corresponding segment of the record.Algorithm 2:Pseudocode of initiation algorithm of fuzzy-based traffic congestion evaluation.
Initiation Algorithm of Fuzzy-based Traffic Congestion Evaluation (1) UpdateIND=0 (2) UpdateINV=0 (3) Foreach rok∈ROdo (4)  Ifrok.congestion_coefficient_value > 1 then (5)   Evaluation(rok) (6)  End if (7)  Else (8)   UpdateINDrok=Get_update(rok,IND) (9)   UpdateINVrok=Get_update(rok,INV) (10)   IfUpdateINDrok/UpdateINVrok>rok.congestion_coefficient_valuethen (11)    Evaluation(rok) (12)   End if (13)   Else exit (14)  End else (15) End forThe control center selects the header for each road segment with a high possibility of traffic congestion. Normally, the vehicle that has remained for the longest in each road segment is selected as a header to maximize stability. For example, a bus that has spent the longest time in a particular road segment is selected as the grid header. In rare situations, in which no vehicle is equipped with an onboard smart device for header selection or most vehicles, including the selected header, tend to leave the segment in an extremely short time before the completion of traffic-flow estimation or local traffic prediction, the control center is assigned to finalize uncompleted tasks to guarantee stability. Consequently, each header subscribes to a VD data topic that is maintained by the control center to track real-time VD data. The real-time VD data are used to estimate the traffic density and velocity performance index of the road segment by using (12) and (13). The estimation results are published to the control center by using the MQTT publish method for maintaining traffic data topic and used as input variables for fuzzy rules-based traffic congestion evaluation.Traffic congestion situation is directly linked with high values of the density performance index. Consequently, the high category of the density performance index is divided into two further categories, high and very high. Thus, the input variables are divided into fuzzy categories: the fuzzy categories of the density performance index are very high, high, medium, and low. The fuzzy categories of the velocity performance index are low, medium, and high. The partial degrees of membership functions are defined as shown in Figure2. The output fuzzy categories reflect traffic congestion levels, which are assigned, according to Taichung City Government’s traffic congestion classification framework, into four categories: free flow, stable flow, unstable flow, and congested. The fuzzy rules are defined to evaluate output fuzzy categories on the basis of input fuzzy categories, which are shown in Table 4. Finally, the fuzzy rules-based traffic congestion condition is evaluated using the header.Table 4
Fuzzy rules for traffic congestion evaluation.
Velocity performance index Low Medium High Density performance index Low Stable flow Free-flow Free-flow Medium Unstable flow Stable flow Free-flow High Congested Unstable flow Stable flow Very High Congested Unstable flow Stable flowFigure 2
Velocity and density performance index membership function.


### 3.4.3. Traffic Congestion Condition Verification

To minimize false predictions, the authors propose traffic congestion condition verification. Whereas traffic congestion predictions involve employing road segment traffic velocity and density characteristics to predict the traffic congestion condition, the traffic congestion verification process entails analyzing the close relationship between a road segment under investigation and neighboring road segments to verify the traffic congestion condition of the road segment.This relationship is used in traffic congestion verification because of the shock wave phenomenon, in which each road segment transfers traffic pressure to its neighboring. This phenomenon may cause traffic congestion on neighboring road segments and was first mentioned by Franklin [24]. A shock wave is a type of kinematic wave. A shock wave occurs when two continuous road segments r1 and r2 encounter density shock (dr>0, where dr=dr2-dr1). The velocity Vs of the shock wave can be obtained using theRankine-Hugoniot conditions [25], as shown in the following:(9)Vs=frdr=fr2-fr1dr2-dr1.Obviously, the direction awareness of Vs depends on the sign of the result of subtracting outflow traffic fr2 from inflow traffic fr1, since outflow traffic fr2 being less than inflow traffic fr1 implies an upstream moving shock (Vs<0), which directly indicates a congested [22].On this basis, the proposed traffic congestion verification proceeds as follows. When a road segment experiences a congestion condition as defined using the fuzzy rules-based method, traffic congestion verification is triggered by the control center. The control center thereafter maintains a traffic-flow topic for each road segment as illustrated in Figure3, which allows the system to store information on traffic flow and traffic direction for each road segment. Meanwhile, the control center maintains an inflow neighbor table for each road segment for managing inflow, as illustrated in Table 5. The content of the inflow neighbor table is derived from corresponding traffic-flow tables. Using the inflow neighbor table of a particular road segment, the control center selects a header in each road segment. Each header is thereafter responsible for traffic data estimation within its road segment. The headers periodically upload flow value and density value information for their road segments. Traffic data estimation follows (6) and (7). Once the traffic data of the road segments have been estimated, the verification process begins, during which the traffic data of road segments under investigation and inflow neighboring road segments, including flow and density values, are collected. The headers transmit the data to the control center for verification by using the MQTT publish method. Subsequently, using the data received from the headers of road segments under investigation and inflow neighboring road segments, the control center examines whether the data fulfil the Rankine-Hugoniot conditions. The Rankine-Hugoniot conditions are evaluated under this circumstance, as expressed in (10). A congested condition is confirmed when Vs<0.(10)Vs=frdr=frivs-∑frinfdrivs-∑drinf,where Vs is the shock wave velocity;fr is the flow shock;dr is the density shock;frivs is the outflow of the road segment under investigation;frinf is the inflow to the road segment under investigation from the inflow neighboring road segment;drivs is the density of the road segment under investigation;drinf is the inflow to the road segment under investigation from the inflow neighboring road segment.Table 5
Inflow neighbor table.
Segment ID Inflow neighborFigure 3
Traffic flows MQTT topic.The following assumptions are defined to explain the congestion verification process:1.
R={r1,r2,…} indicates a set of road segments.2.
G={g1,g2,…} indicates a set of grid headers.The algorithm used for traffic congestion verification is described as shown in Algorithm3.Algorithm 3:Pseudocode of traffic congestion condition verification.
Traffic Congestion Condition Verification Operation (1) If(Fuzzy_Based_Evaluation(rc) == ‘congested’) then (2)  Verfication_Result =NULL (3)  Foreach rido (4)   If(Exist_Outflow(lanej,rk) == true) then (5)   Update_Neighbor(rj) to inflow neighbor table of rk (6)   End if (7)  End For (8)  Foreach inflow neighbor rk of rcdo (9)   grk = Select_header(rk) (10)  End for (11)  While(Verfication_Result=NULL)do (12)   grc performs Update_traffic(flow, density) to traffic flow table of rc (13)   grc performs Publish(flow, density, rc) to the control center (14)   For each inflow neighbor rk of rcdo (15)     grk performs Update_traffic(flow, density) to traffic flow table of rk (16)     grk performs Publish(flow, density, rk) to the control center (17)End For (18)doRankine-Hugoniot_Validation(ri,rk1,rk2,…,rkn) (19)If (Rankine-Hugoniot_Validation(ri,rk1,rk2,…,rkn)<0)then (20)Verfication_Result== ‘Verified’ (21)ElseVerfication_Result==‘Failed’ (22)     Fuzzy_Based_Evaluation(rc) = ‘unstable-flow’ (23)End while (24)End if


## 3.4.1. Traffic Congestion Observation Table

To identify road segments at a high risk of traffic congestion and provide a global view of traffic transition, the authors used historical VD data for traffic analysis to build a traffic congestion observation table. In the past, density and velocity characteristics were used in a simple combination of their value range to determine the traffic congestion condition. For example, traffic congestion is identified in a road, which has a high vehicle density and a low velocity value. However, this strategy has limitations attributable to range value classification, because the range values of density and velocity vary greatly from road to road. This may cause inaccurate estimation and failure in traffic congestion prediction. Because of this problem, the authors propose the traffic congestion coefficient (TCC) concept, which represents the possibility of a traffic congestion condition existing on a large-scale road network. The TCC is calculated as shown in the following:(8)TCC=IdIvIND=dDmaxINV=vVmax,if  all  lanes  have  the  sameVmax∑k=1mVelocityavglanek/VMaxlanekm,if  each  lane  have  a  differentVmax,whereId is the density performance index;Iv is the velocity performance index;d is the average density of the road segment;v is the average velocity of the road segment;Vmax is the maximum limitation velocity of road segment;Dmax is the maximum recorded density in the road segment;Velocityavglanek is the average velocity of lane k in the road segment;VMaxlanek is the maximum limitation velocity of lane k in the road segment;l is the road segment length;m is the number of lanes which have the same travel direction.Because VD data records are extremely numerous, the records should be effectively analyzed to derive useful information. Thus, the authors divided historical VD records into seven sets, one for each day of the week, and then divided each set into 24 subsets, one for each hour of the day. Once the historical VD data records had been classified, the congestion coefficient value of segments in each set was calculated. The following assumptions are defined to explain the calculation efficiently:1.
W={Mon,Tue,Wed,Thu,Fri,Sat,Sun} indicates the day of the week of investigation.2.
TI={(0-1),(1-2),…,(23-24)} indicates the time interval of investigation.3.
TD={td0,td1} indicates the travel direction.4.
Rij={r1,r2,…,ru} indicates a set of historical VD records on day of the week i∈W and in time slot j∈TI.5.
RID={rid1,rid2,…,ridn} indicates the set of road segment IDs.6.
TCCijrid(td) indicates the TCC of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.7.
INDijrid(td) indicates the density performance index of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.8.
INVijrid(td) indicates the velocity performance index of travel directiontd of road segmentrid on day of the week i∈W and in time slot j∈T.9.
Dmaxrid(td) indicates the maximum recorded density of road segmentrid.10.
Nijrid(td) indicates the number of historical TCCs of road segmentrid on day of the week i∈W and in time slot j∈T.The following TCC calculation algorithm should be executed at the end of the day of the weeki and time slot j as shown in Algorithm 1.1.
(Lines(1)–(4)) First, INDijrid(td), INVijrid(td), Dijrid(td), and counterrid(td) variables, which are used for TCC calculation for each road segment on day of the week i and in time slot j are initialized. INDijrid(td) represents the density performance index value; INVijrid(td) represents the velocity performance index value; Dijrid(td) represents the density value; counterrid(td) denotes the number of records for each day of the week i and time slot j. At the beginning, variable values are assigned as zero or NULL.2.
(Lines(5)–(11)) Second, each historical VD data record is investigated to extract the speed and volume information of vehicles. The information is classified by road segment. The calculation results are temporarily expressed as the INVijrid(td) and Dijrid(td) variables of each road segment.3.
(Lines(12)–(15)) Third, the previous values of TCC, number of TCC calculation, and max density are read for TCC calculation.4.
(Lines(16)–(19)) To improve the accuracy of density performance index calculation, the estimated density value of the current session is evaluated by comparing it with the maximum density. If the current density value is greater than the maximum density value, the maximum density value is updated as the current density value.5.
(Lines(20)–(22)) Subsequently, the TCC of each road segment in time slot j and day of the week i is calculated on the basis of (8), (12), and (13), which considers both current session data and previous session data.6.
(Lines(23)–(26)) Finally, the calculated TCC value and the number of TCC calculation session of each road segment are stored in the database for the next TCC calculation session.Algorithm 1:Pseudocode of TCC calculation algorithm.
TCC Calculation Algorithm (1) INDijrid(td)=0 (2) INVijrid(td)=0 (3) Dijrid(td)=0 (4) counterrid(td)=0 (5) Foreach rk∈Rijdo (6)  Ifrk.device_id = ridp and rk.travel_direction=tdqthen (7)      INVijridp(tdq)=INVijridp(tdq)+rk.Vavgrk.VMax (8)      Dijridp(tdq)=Dijridp(tdq)+rk.Vehicle_volumeLengthridp (9)      counterridp(tdq)=counterridp(tdq)+1 (10)  End if (11)  End for (12) Foreach traveling direction tdq∈TD of ridp∈RIDdo (13)  Read (TCCijridptdq) (14)  Read (Nijridptdq) (15)  Read (DijMaxridptdq) (16)  If(Dijridp(tdq)∗ridp.number_of_lanes)/counterridp(tdq)>DijMaxridp(tdq)then (17)DijMaxridp(tdq)⟵Dijridp(tdq)∗ridp.number_of_lanescounterridp(tdq) (18)     Write(DijMaxridptdq) (19)End if (20)INVijridp(tdq)=INVijridp(tdq)counterridp(tdq) (21)INDijridp(tdq)=Dijridp(tdq)∗ridp.number_of_lanescounterridp(tdq)∗DijMaxridp(tdq) (22)TCCijridp(tdq)=TCCijridp(tdq)∗Nijridptdq+INDijridp(tdq)/INVijridp(tdq)Nijridp(tdq)+1 (23)Nijridk=Nijridk+1 (24)  Write(TCCijridptdq) (25)  Write(TCCijridptdq) (26)End forThe calculation results are maintained as tables in the control center; each table corresponds to a set of historical VD data as illustrated in Table3. Furthermore, to quantify the TCC values, the authors define two types of road segments on the basis of their correlated range of TCC values: first, a road segment with a high possibility of traffic congestion has a TCC value greater than 1; second, a road segment with a low possibility of traffic congestion has a TCC value equal to or lower than 1. The first type has a high possibility of traffic congestion, whereas the second type is almost traffic congestion free. If a road segment’s TCC value equals 1, its density and velocity correlate sufficiently to guarantee stable traffic conditions on the road.Table 3
Traffic congestion observation table.
Day of week Time interval Segment ID Location Congestion coefficient value Sat. (17-18) V069320 (24.145285, 120.632205) 1.25 Sat. (17-18) V029500 (24.17083, 120.685352) 0.8


## 3.4.2. Fuzzy-Based Traffic Congestion Evaluation

Fuzzy rules-based methods are a particularly suitable solution for addressing complex nondeterministic problems, including transportation field [23]. In this paper, the authors propose a fuzzy logic-based traffic congestion evaluation method that uses the estimated traffic density and velocity performance index of a road segment as input parameters. The proposed method provides the results of traffic congestion level evaluation. The method is applied to road segments that are at a high risk of traffic congestion as determined using the traffic congestion observation table and from segments discovered to have traffic-flow values higher than usual. The following assumptions are defined to explain the algorithm.1.
RO={ro1,ro2,…,roz} denotes the set of records in the corresponding traffic congestion observation table of the evaluation.2.
UpdateIND denotes an updated density performance index value of a segment.3.
UpdateINV denotes an updated velocity performance index value of a segment.The following initiation algorithm should be executed to start fuzzy rule-based traffic congestion evaluation, as presented in Algorithm2.1.
(Lines(1)-(2)) First, the UpdateIND and UpdateINV, which are used to store updated density performance index value and velocity performance index value of a segment, are initialized. At the beginning, variable values are assigned as zero.2.
(Lines(3)–(6)) Second, each record of traffic congestion observation table is investigated to decide which segments need to be evaluated using fuzzy rules-based traffic congestion evaluation. If the current coefficient value is greater than 1, the fuzzy rules-based traffic congestion evaluation is activated on the corresponding segment of the record.3.
(Lines(7)–(15)) Third, if the current coefficient value is smaller than or equal to one, then the density performance index value UpdateIND and velocity performance index value UpdateINV of the corresponding segment will be updated. Under this circumstance, if division UpdateIND by UpdateINV is greater than current coefficient value, which may represent an abnormal traffic congestion situation. Subsequently, the fuzzy rules-based traffic congestion evaluation is required to perform on the corresponding segment of the record.Algorithm 2:Pseudocode of initiation algorithm of fuzzy-based traffic congestion evaluation.
Initiation Algorithm of Fuzzy-based Traffic Congestion Evaluation (1) UpdateIND=0 (2) UpdateINV=0 (3) Foreach rok∈ROdo (4)  Ifrok.congestion_coefficient_value > 1 then (5)   Evaluation(rok) (6)  End if (7)  Else (8)   UpdateINDrok=Get_update(rok,IND) (9)   UpdateINVrok=Get_update(rok,INV) (10)   IfUpdateINDrok/UpdateINVrok>rok.congestion_coefficient_valuethen (11)    Evaluation(rok) (12)   End if (13)   Else exit (14)  End else (15) End forThe control center selects the header for each road segment with a high possibility of traffic congestion. Normally, the vehicle that has remained for the longest in each road segment is selected as a header to maximize stability. For example, a bus that has spent the longest time in a particular road segment is selected as the grid header. In rare situations, in which no vehicle is equipped with an onboard smart device for header selection or most vehicles, including the selected header, tend to leave the segment in an extremely short time before the completion of traffic-flow estimation or local traffic prediction, the control center is assigned to finalize uncompleted tasks to guarantee stability. Consequently, each header subscribes to a VD data topic that is maintained by the control center to track real-time VD data. The real-time VD data are used to estimate the traffic density and velocity performance index of the road segment by using (12) and (13). The estimation results are published to the control center by using the MQTT publish method for maintaining traffic data topic and used as input variables for fuzzy rules-based traffic congestion evaluation.Traffic congestion situation is directly linked with high values of the density performance index. Consequently, the high category of the density performance index is divided into two further categories, high and very high. Thus, the input variables are divided into fuzzy categories: the fuzzy categories of the density performance index are very high, high, medium, and low. The fuzzy categories of the velocity performance index are low, medium, and high. The partial degrees of membership functions are defined as shown in Figure2. The output fuzzy categories reflect traffic congestion levels, which are assigned, according to Taichung City Government’s traffic congestion classification framework, into four categories: free flow, stable flow, unstable flow, and congested. The fuzzy rules are defined to evaluate output fuzzy categories on the basis of input fuzzy categories, which are shown in Table 4. Finally, the fuzzy rules-based traffic congestion condition is evaluated using the header.Table 4
Fuzzy rules for traffic congestion evaluation.
Velocity performance index Low Medium High Density performance index Low Stable flow Free-flow Free-flow Medium Unstable flow Stable flow Free-flow High Congested Unstable flow Stable flow Very High Congested Unstable flow Stable flowFigure 2
Velocity and density performance index membership function.


## 3.4.3. Traffic Congestion Condition Verification

To minimize false predictions, the authors propose traffic congestion condition verification. Whereas traffic congestion predictions involve employing road segment traffic velocity and density characteristics to predict the traffic congestion condition, the traffic congestion verification process entails analyzing the close relationship between a road segment under investigation and neighboring road segments to verify the traffic congestion condition of the road segment.This relationship is used in traffic congestion verification because of the shock wave phenomenon, in which each road segment transfers traffic pressure to its neighboring. This phenomenon may cause traffic congestion on neighboring road segments and was first mentioned by Franklin [24]. A shock wave is a type of kinematic wave. A shock wave occurs when two continuous road segments r1 and r2 encounter density shock (dr>0, where dr=dr2-dr1). The velocity Vs of the shock wave can be obtained using theRankine-Hugoniot conditions [25], as shown in the following:(9)Vs=frdr=fr2-fr1dr2-dr1.Obviously, the direction awareness of Vs depends on the sign of the result of subtracting outflow traffic fr2 from inflow traffic fr1, since outflow traffic fr2 being less than inflow traffic fr1 implies an upstream moving shock (Vs<0), which directly indicates a congested [22].On this basis, the proposed traffic congestion verification proceeds as follows. When a road segment experiences a congestion condition as defined using the fuzzy rules-based method, traffic congestion verification is triggered by the control center. The control center thereafter maintains a traffic-flow topic for each road segment as illustrated in Figure3, which allows the system to store information on traffic flow and traffic direction for each road segment. Meanwhile, the control center maintains an inflow neighbor table for each road segment for managing inflow, as illustrated in Table 5. The content of the inflow neighbor table is derived from corresponding traffic-flow tables. Using the inflow neighbor table of a particular road segment, the control center selects a header in each road segment. Each header is thereafter responsible for traffic data estimation within its road segment. The headers periodically upload flow value and density value information for their road segments. Traffic data estimation follows (6) and (7). Once the traffic data of the road segments have been estimated, the verification process begins, during which the traffic data of road segments under investigation and inflow neighboring road segments, including flow and density values, are collected. The headers transmit the data to the control center for verification by using the MQTT publish method. Subsequently, using the data received from the headers of road segments under investigation and inflow neighboring road segments, the control center examines whether the data fulfil the Rankine-Hugoniot conditions. The Rankine-Hugoniot conditions are evaluated under this circumstance, as expressed in (10). A congested condition is confirmed when Vs<0.(10)Vs=frdr=frivs-∑frinfdrivs-∑drinf,where Vs is the shock wave velocity;fr is the flow shock;dr is the density shock;frivs is the outflow of the road segment under investigation;frinf is the inflow to the road segment under investigation from the inflow neighboring road segment;drivs is the density of the road segment under investigation;drinf is the inflow to the road segment under investigation from the inflow neighboring road segment.Table 5
Inflow neighbor table.
Segment ID Inflow neighborFigure 3
Traffic flows MQTT topic.The following assumptions are defined to explain the congestion verification process:1.
R={r1,r2,…} indicates a set of road segments.2.
G={g1,g2,…} indicates a set of grid headers.The algorithm used for traffic congestion verification is described as shown in Algorithm3.Algorithm 3:Pseudocode of traffic congestion condition verification.
Traffic Congestion Condition Verification Operation (1) If(Fuzzy_Based_Evaluation(rc) == ‘congested’) then (2)  Verfication_Result =NULL (3)  Foreach rido (4)   If(Exist_Outflow(lanej,rk) == true) then (5)   Update_Neighbor(rj) to inflow neighbor table of rk (6)   End if (7)  End For (8)  Foreach inflow neighbor rk of rcdo (9)   grk = Select_header(rk) (10)  End for (11)  While(Verfication_Result=NULL)do (12)   grc performs Update_traffic(flow, density) to traffic flow table of rc (13)   grc performs Publish(flow, density, rc) to the control center (14)   For each inflow neighbor rk of rcdo (15)     grk performs Update_traffic(flow, density) to traffic flow table of rk (16)     grk performs Publish(flow, density, rk) to the control center (17)End For (18)doRankine-Hugoniot_Validation(ri,rk1,rk2,…,rkn) (19)If (Rankine-Hugoniot_Validation(ri,rk1,rk2,…,rkn)<0)then (20)Verfication_Result== ‘Verified’ (21)ElseVerfication_Result==‘Failed’ (22)     Fuzzy_Based_Evaluation(rc) = ‘unstable-flow’ (23)End while (24)End if


## 3.5. Origin-Destination Traffic Congestion Service for Drivers

An origin-destination traffic congestion service is proposed to provide on-the-way congestion information for drivers who travel through road segments to their destination. The origin-destination traffic congestion service is used when a traffic congestion condition has been verified on a road segment and the preselected travel route of the vehicle traverses the verified road segment. The workflow of the proposed mechanism is detailed as follows: once a congested condition has been verified on a road segment, the control center establishes the segments order number as 1 to denote the road segment as a level 1 congestion road segment, creates an event ID for the congestion, and changes the road segment’s status to ‘congested.’ Vehicles on the inflow neighboring road segments are then informed of the congested status. Thereafter, each header of inflow neighboring road segments that are classified as level 2 congestion road segments updates the order value by increasing it by 1. This task is repeated sequentially for level three congestion road segments and so on. The task is completed when all interrelated inflow neighboring road segments have updated their congestion status. Once the process has been completed, each vehicle with a unique traveling route that directly passes through the verified congested segment will estimate origin-destination traffic congestion information based on the instant distance to the congested road segment and the velocity of the vehicle, as illustrated in Figure5.


## 4. System Prototype and Implementation

To provide traffic congestion monitoring service for drivers, this study designed and implemented a simple prototype system. We describe the framework of this prototype in this section. Figure4 illustrates the system architecture, which consists of three parts: vehicles, the VD sensors subsystem, and the control center subsystem. In the system, each vehicle is equipped with an onboard smart device. The onboard smart device allows drivers to receive traffic notifications from the system and displays vehicle journey information. The VD sensor subsystem is used to collect traffic data and send the collected data to the control center. The VD sensor subsystem includes VD sensors and a roadside unit (RSU). The RSU is an embedded platform equipped with two types of communication interface. The first interface is used to directly connect to the VD device. The second interface is used for wireless communication to connect to the control center subsystem using the web API. The collected data are then analyzed to characterize traffic-flow conditions. Then, the analyzed data are uploaded to the system database and act as a source of historical data for determining locations at risk of future traffic congestion in order to provide a more effective traffic congestion monitoring service. The control center subsystem includes an MQTT broker, a control center unit, and a database. The MQTT broker is established to provide an MQTT connection as the core connection for both vehicles and the VD sensors subsystem. This allows vehicles and the VD sensor subsystem to communicate with the control center unit. This unit is in turn responsible for data collection, data analysis, observation table maintenance, and publish/subscribe management to provide appropriate notifications to drivers.Figure 4
System architecture.Figure 5
Client interface of traffic congestion monitoring system.For the first part of implementation, a simple application was designed to provide traffic-flow information regarding the current road segment where the vehicle and the origin-destination traffic congestion services are located. Drivers can use the onboard device with an integrated 3G or LTE interface to connect to the control center through the MQTT broker. For the second part implementation, an MQTT broker was established on a Windows-based server. The authors used Mosquitto, an open-source message broker, as the MQTT broker deployment package, which implements the MQTT protocol versions 3.1 and 3.1.1. The established MQTT broker allows drivers, the control center, and VD sensors to implement the publish/subscribe mechanism by using the public MQTT broker IP address and available topic name. For the final part implementation, the control center was implemented on a Microsoft Windows server-based host; the interface was designed using Microsoft Visual Studio 2015 as the integrated development environment and C# as the programming language. The ADO.NET entity data model was used to manipulate data exchange between the control center and database.Figure5 shows the application interface, which is designed for the driver. The interface displays the vehicle’s speed and traffic-flow information regarding the current road segment. The driver can easily observe the traffic congestion state of the road segment and the entire predefined travel route. If traffic congestion occurs in any upcoming road segment on the predefined route, the application alerts the driver in advance and estimates the time remaining before reaching the area of congestion. This actively assists the driver in efficiently traveling to the destination. Figure 6 presents various types of traffic congestion information obtained from the road network that are used to assist the government’s transportation division think tank, including congestion maps and detailed information of all segments and reports.Figure 6
Control center interface of traffic congestion monitoring system.


## 5. Experimental Results

The authors present the results in two subsections. The first subsection presents the TCC analysis results. The second subsection presents the evaluation results of the proposed traffic congestion monitoring scheme. Eclipse Neon, a Java EE IDE, was used as the environmental development tool to evaluate the average system response time of the proposed system in comparison with traditional HTTP protocol base systems. Furthermore, MATLAB version R2016a was used to evaluate the performance of the proposed monitoring method in comparison withK-Nearest Neighbor method.


### 5.1. Analysis Results of Traffic Congestion Coefficient

The TCC was calculated for each road segment on the basis of its velocity performance index and density performance index, which were categorized according to hours of the day and days of the week. Figure7 indicates that the analysis results of TCC distribution on Wenxin Road Section 3, a school area, where there are several elementary and high schools. Due to this characteristic, the Wenxin Road Section 3 has significantly decreased the number of vehicles on weekends and increased the number of vehicles on weekdays, which directly affect the corresponding TCC values.Figure 7
Traffic congestion coefficient analysis result of school area.
(a)
School area, Wenxin Rd. Sec. 3 (first direction) (b)
School area, Wenxin Rd. Sec. 3 (second direction)By contrast, the distributions of high TCC values on Gongyi Road Section 2, a business area, retained a stable distribution on both weekdays and weekends as shown in Figure8. The Gongyi Road Section 2 area is concentrated on daily life services such as shopping, dining, and banking. Figures 7 and 8 also reveal that the time distributions of high TCC values in both areas, school area and business area, are similar; peak times are approximately 8–10 a.m. and 5–7 p.m.Figure 8
Traffic congestion coefficient analysis result of business area.
(a)
Business area, Gongyi Rd. Sec. 2 (first direction) (b)
Business area, Gongyi Rd. Sec. 2 (second direction)The usability of TCC in identifying high risk of traffic congestion areas is also demonstrated as shown in Figure9, where Taiwan Boulevard Section 2, a main road in the city center, which usually faces the traffic congestion situation is marked with a much higher TCC value than that of Chongde Road, a suburban road.Figure 9
Area-based traffic congestion coefficient comparison.
(a)
Area comparison, weekdays (b)
Area comparison, weekends


### 5.2. Average System Response Time

To evaluate the system response time of the proposed system, which uses the Mosquitto MQTT protocol in comparison with the conventional HTTP-based systems such as Jayapal and Roy [26] or Sukode and Gite [1], an experimental HTTP server and Mosquitto MQTT broker environment were established on a local Microsoft Windows server-based host, and Java was used as the implementation programming language to evaluate simultaneous data transmission from vehicles to the HTTP server or MQTT broker. Figure 10 shows system response time results for HTTP and Mosquitto MQTT. MQTT ran in three quality of service (QoS) modes, namely, 0(at most once), 1(at least once), and 2(exactly once). MQTT QoS mode 0 is the fastest; in this mode, the sender delivers messages across the network without an acknowledgement being sent. By contrast, MQTT QoS mode 2 is the slowest but the safest mode; at least two pairs of transmissions must be exchanged between sender and receiver to guarantee that messages are properly received by the receiver before they are deleted on the sender’s side. MQTT QoS mode 1, in which the sender must receive an acknowledgement before sending a new message, is the default transfer mode and was used in the system prototype. The results demonstrate that the proposed system with MQTT outperformed the conventional HTTP-based system in system response time.Figure 10
System response time.


### 5.3. Local Segment Traffic Congestion Prediction Result

This subsection describes an evaluation of the performance of the proposed fuzzy rules-based local segment traffic congestion prediction conducted using MATLAB version R2016a. To evaluate performance in real-world conditions, real data recorded in May 2014 on Taiwan Boulevard Section 2 were adopted as the experimental environment and parameter values for the evaluation.Figure11(a) depicts the prediction results obtained using the k-nearest neighbor method with k = 5. The results show that the k-nearest neighbor method predictions properly predict the congestion state at the lowest traffic congestion level but exhibit decreased accuracy at higher congestion levels. In particular, the k-nearest neighbor method failed to predict some states of the highest congestion levels, which occurred at approximately 2 p.m. and 5 p.m. Figure 11(b) shows the prediction results for the proposed fuzzy rules-based method without a verification process. The proposed method produces a prediction result identical to that of the k-nearest neighbor method at the lowest level of traffic congestion but has improved accuracy at higher congestion levels. Furthermore, the proposed method can determine highest-level traffic congestion states which have been incorrectly predicted using the k-nearest neighbor method. However, without the verification process, several failed predictions occurred between 1 p.m. and 2 p.m. Figure 11(c) shows the prediction results for the proposed fuzzy rules-based method along with the verification process, which demonstrates that the verification process eliminated failed predictions during states of high-level traffic congestion, indicating the accuracy of the prediction.Figure 11
Traffic congestion evaluation results.
(a)
K-nearest neighbor method (b)
Proposed method without verification process (c)
Proposed method with verification processFigure12 provides a performance comparison of the aforementioned methods. Figure 12(a) depicts a performance comparison under the normal traffic condition. The normal traffic condition implies traffic congestion of levels 1 and 2, as indicated in Figure 11. The results revealed that the proposed method outperformed the traditional k-nearest neighbor method. Because the normal traffic condition does not imply a congested situation (i.e., traffic congestion level 3), no verification is activated. Thus, the proposed method with verification was determined to retain identical performance to the original method for low levels of traffic congestion. Figure 12(b) provides a performance comparison under the high traffic condition in which traffic congestion level 3 is implied. Under this condition, the proposed method demonstrated its comparative effectiveness in predicting congested situations with verification, providing a high success rate of approximately 81%. Figure 12(c) depicts the overall performance comparison. The overall rate indicates the 24-hour performance of these methods. The results revealed that the proposed method outperformed the k-nearest neighbor method with a greater than 10% lower error rate.Figure 12
Performance comparison.
(a)
Normal traffic demand condition (b)
High traffic demand condition (c)
Overall rate


## 5.1. Analysis Results of Traffic Congestion Coefficient

The TCC was calculated for each road segment on the basis of its velocity performance index and density performance index, which were categorized according to hours of the day and days of the week. Figure7 indicates that the analysis results of TCC distribution on Wenxin Road Section 3, a school area, where there are several elementary and high schools. Due to this characteristic, the Wenxin Road Section 3 has significantly decreased the number of vehicles on weekends and increased the number of vehicles on weekdays, which directly affect the corresponding TCC values.Figure 7
Traffic congestion coefficient analysis result of school area.
(a)
School area, Wenxin Rd. Sec. 3 (first direction) (b)
School area, Wenxin Rd. Sec. 3 (second direction)By contrast, the distributions of high TCC values on Gongyi Road Section 2, a business area, retained a stable distribution on both weekdays and weekends as shown in Figure8. The Gongyi Road Section 2 area is concentrated on daily life services such as shopping, dining, and banking. Figures 7 and 8 also reveal that the time distributions of high TCC values in both areas, school area and business area, are similar; peak times are approximately 8–10 a.m. and 5–7 p.m.Figure 8
Traffic congestion coefficient analysis result of business area.
(a)
Business area, Gongyi Rd. Sec. 2 (first direction) (b)
Business area, Gongyi Rd. Sec. 2 (second direction)The usability of TCC in identifying high risk of traffic congestion areas is also demonstrated as shown in Figure9, where Taiwan Boulevard Section 2, a main road in the city center, which usually faces the traffic congestion situation is marked with a much higher TCC value than that of Chongde Road, a suburban road.Figure 9
Area-based traffic congestion coefficient comparison.
(a)
Area comparison, weekdays (b)
Area comparison, weekends


## 5.2. Average System Response Time

To evaluate the system response time of the proposed system, which uses the Mosquitto MQTT protocol in comparison with the conventional HTTP-based systems such as Jayapal and Roy [26] or Sukode and Gite [1], an experimental HTTP server and Mosquitto MQTT broker environment were established on a local Microsoft Windows server-based host, and Java was used as the implementation programming language to evaluate simultaneous data transmission from vehicles to the HTTP server or MQTT broker. Figure 10 shows system response time results for HTTP and Mosquitto MQTT. MQTT ran in three quality of service (QoS) modes, namely, 0(at most once), 1(at least once), and 2(exactly once). MQTT QoS mode 0 is the fastest; in this mode, the sender delivers messages across the network without an acknowledgement being sent. By contrast, MQTT QoS mode 2 is the slowest but the safest mode; at least two pairs of transmissions must be exchanged between sender and receiver to guarantee that messages are properly received by the receiver before they are deleted on the sender’s side. MQTT QoS mode 1, in which the sender must receive an acknowledgement before sending a new message, is the default transfer mode and was used in the system prototype. The results demonstrate that the proposed system with MQTT outperformed the conventional HTTP-based system in system response time.Figure 10
System response time.


## 5.3. Local Segment Traffic Congestion Prediction Result

This subsection describes an evaluation of the performance of the proposed fuzzy rules-based local segment traffic congestion prediction conducted using MATLAB version R2016a. To evaluate performance in real-world conditions, real data recorded in May 2014 on Taiwan Boulevard Section 2 were adopted as the experimental environment and parameter values for the evaluation.Figure11(a) depicts the prediction results obtained using the k-nearest neighbor method with k = 5. The results show that the k-nearest neighbor method predictions properly predict the congestion state at the lowest traffic congestion level but exhibit decreased accuracy at higher congestion levels. In particular, the k-nearest neighbor method failed to predict some states of the highest congestion levels, which occurred at approximately 2 p.m. and 5 p.m. Figure 11(b) shows the prediction results for the proposed fuzzy rules-based method without a verification process. The proposed method produces a prediction result identical to that of the k-nearest neighbor method at the lowest level of traffic congestion but has improved accuracy at higher congestion levels. Furthermore, the proposed method can determine highest-level traffic congestion states which have been incorrectly predicted using the k-nearest neighbor method. However, without the verification process, several failed predictions occurred between 1 p.m. and 2 p.m. Figure 11(c) shows the prediction results for the proposed fuzzy rules-based method along with the verification process, which demonstrates that the verification process eliminated failed predictions during states of high-level traffic congestion, indicating the accuracy of the prediction.Figure 11
Traffic congestion evaluation results.
(a)
K-nearest neighbor method (b)
Proposed method without verification process (c)
Proposed method with verification processFigure12 provides a performance comparison of the aforementioned methods. Figure 12(a) depicts a performance comparison under the normal traffic condition. The normal traffic condition implies traffic congestion of levels 1 and 2, as indicated in Figure 11. The results revealed that the proposed method outperformed the traditional k-nearest neighbor method. Because the normal traffic condition does not imply a congested situation (i.e., traffic congestion level 3), no verification is activated. Thus, the proposed method with verification was determined to retain identical performance to the original method for low levels of traffic congestion. Figure 12(b) provides a performance comparison under the high traffic condition in which traffic congestion level 3 is implied. Under this condition, the proposed method demonstrated its comparative effectiveness in predicting congested situations with verification, providing a high success rate of approximately 81%. Figure 12(c) depicts the overall performance comparison. The overall rate indicates the 24-hour performance of these methods. The results revealed that the proposed method outperformed the k-nearest neighbor method with a greater than 10% lower error rate.Figure 12
Performance comparison.
(a)
Normal traffic demand condition (b)
High traffic demand condition (c)
Overall rate


## 6. Conclusion

This paper proposes a distributed traffic congestion monitoring system on the IoV. The system responsively reacts to numerous requests concerning the traffic congestion situation by combining the advantages of MQTT, a lightweight protocol that has the ability to support low-bandwidth and high-latency vehicular environments, and VD sensors, which have high reliability and accuracy in traffic-flow monitoring. Furthermore, real-time data were used to formalize the traffic-flow factors and predict traffic congestion states through a fuzzy rule-based scheme. The proposed system not only effectively monitors traffic congestion but also reduces response time. The designed traffic congestion verification process can help in improving local traffic congestion prediction efficiency, and origin-destination traffic congestion service improves service quality, which will be provided for drivers. Experimental results showed that the proposed system was effective in predicting traffic congestion states in terms of accuracy and system response time. In future studies, the authors intend to improve the system’s flexibility by enhancing the segmented structure to a hybrid structure in which traffic-flow estimation can be based on both VD sensors and vehicle-to-vehicle communications. The authors additionally intend to improve local segment traffic congestion prediction and origin-destination traffic congestion service for suitability with the hybrid segmented structure.



---

*Source: 9136813-2018-05-20.xml*