Report Policies for Communication Reduction

The TIC generates the real-time traffic information based on the traveling data of the GPS-equipped probes. One of the design issues is how often the probes should send traveling data to the TIC. In conventional systems, probes send reports to the TIC periodically, for example, Schaefer et al. [11] proposed an urban traffic information system using GPS-equipped probe taxis, and each taxi has to send the GPS position to taxi headquarters at least once per minute. One of the advantages of periodical reports is that it is easy to implement. Traffic information of a road segment can be obtained as long as a probe vehicle travels by. However, when GPS-equipped smart phones are used as probes, there may be a large number of probes on a road segment. As a result, many redundant traffic reports would be sent to the TIC. This wastes the valuable wireless transmission bandwidth and may over-load the TIC’s computation resources.

B. Hoh et al. [12] has use virtual trip lines to collect the traffic information. The virtual trip line can be figure as follow:

Fig. 2-1 An example of virtual trip line

8

A virtual trip line (VTL) is a line in geographic space that, when vehicles cross, triggers a client’s location update to the traffic monitoring server. More specially, it is define by

[id, x1, y1, x2, y2, d]

Where id, is the trip line ID, x1, y1, x2, and y2 are the (x, y) coordinates of two line endpoints, and d is a default direction vector. When a vehicle traverse the trip line, its location update comprises time, trip line ID, speed, and the direction of crossing. The trip lines are pre-generated and stored in probes. The advantage of the virtual trip line approach is that it reduces the number of reports to only once in a segment. However, as the number of probes increases, there will be redundant reports for the same segment from different probes sent to the TIC.

Van Buer et al. [13] proposed a notification system for reporting the traffic anomaly condition. In their system, each probe car has an on-board database to record its historical travel data, and it determines its speed anomaly during each trip. Each probe car needs to compare its historical database with its current speed, and

determine whether the speed discrepancy is greater than a predefine threshold or not.

If the discrepancy satisfies the predefine threshold, probe car report its current speed to the TIC. When the TIC receives the probe car report, the TIC generates and broadcasts an alert to probe cars on the road segment. After receiving an alert from the TIC, each probe car has to compare its speed discrepancy with the alert, and report to the TIC if the speed discrepancy is greater than a predefine threshold. Table 2-1 is an example of this report policy. In step 2, the probe car detects that the speed discrepancy is equal the predefine threshold (-10 mph), and notifies the TIC that it detects anomaly changes. When the TIC receives the notification, the TIC generates

9

the “Traffic Slow” alert to all probe cars. In step 3, a probe car detects that the speed discrepancy is larger than the “Slow” alert threshold, so the probe car notifies the TIC.

When the TIC receives the notification, it broadcast “Jam” alert to probe cars. The disadvantage of this method is that each probe car compares its current speed with its historic speed data. Since a probe car may be driven by different drivers with different driving behaviors, it is possible that the probe car may generate anomaly traffic data.

Table 2-1 An example of the report policy Reporting Thresholds: -10 kph, -20 kph, +10 kph

Time Seq. Current Speed History Speed PC’s Action TIC’s Action

1 45 40 -- --

Kerner et al. [14] developed a FCD-based traffic information system using a travel time threshold to reduce messages sent to the TIC. In this method, TIC

periodically broadcasts the average travel time and a threshold for each road segment.

By comparing the difference between the received travel time and the travel time record itself with the threshold, the PC decides whether or not to send a report to the TIC. The decision is based on the following equation:

∣ 𝑅_𝑘^(𝑣)− 𝑅_𝑘^(𝑐) ∣< 𝛥𝑅_𝑘^(𝑐) (2.1)

Where 𝑅_𝑘^(𝑣) is the travel time measure by probe car, 𝑅_𝑘^(𝑐) is the travel time broadcasted by the TIC, and 𝛥𝑅_𝑘^(𝑐) is the threshold value. The in-equality above checks if the travel time difference between the probe cars measured value and the

10

TIC broadcasted value is greater than the TIC broadcasted threshold. If the condition is satisfied, the probe car sends the traffic information report to the TIC. Using threshold values does reduce the communication cost, but the accuracy of the generated traffic information may also decrease.

Tanizaki and Wolfson [15] designed a randomized report policy to improve the threshold approach. They define server delay, which is a delay from a probe car sending reports to the TIC till the TIC broadcasts a new threshold. In this delay time interval, there may be a large amount of unanimous traffic information sent to the TIC if there are many probes traveling on the same road segment. To address this problem, when the threshold is satisfied, instead of always sending a report to the TIC, the probe sending the report with a probability p, this is determined by the TIC for each road segment to reduce the number of reports and achieve high accuracy. This reduces the volume of reports sent at the server delay interval, but may result in incomplete traffic data received by the TIC and less real-timeliness of the traffic information generated.

To deal with the issues above, Ayala et al. [16] proposed a flow-based report policy for FCD-based traffic information systems. They don’t use threshold values to determine whether to send the traveling data to the TIC or not. Every probe car has the same probability to transmit the traveling data to the TIC. The transmission

11

probability 𝑝 = 𝑘 / 𝑁, where k is the number of messages that the TIC needs to

receive from probe cars in order to guarantee a given confidence in the average speed computation, and N is the estimated of the flow of vehicles through the road segment during the collection period. When a vehicle reaches the end of a road segment it computes k and N. The sample size k is compute by probes based on central limit theorem, and N is an estimate of the flow of vehicles through the road segment during the collection period. The speed-flow model chosen for the flow-based policy is Greenshields model. The relationship is given by the equation (2.2). Where d is the traffic-jam density, 𝑉_𝑏 is the average velocity of the previous collection period, and V

is the free-flow speed on the given segment. The equation comes from the speed-flow relationship where flow is 0 at zero speed (𝑉_𝑏 = 0) and at free-flow speed (𝑉_𝑏 = 𝑉).

flow ≈ d ∗ 𝑉_𝑏(1 −^𝑉_𝑉^𝑏) (2.2)

Use the equation (2.2) above, one can compute the flow throughout the collection period as equation (2.3), where τ is the length of the collection period (in

seconds) [16].

N = flow ∗ τ (2.3)

After computing the k and N, the probe vehicle transmits the traffic record to the TIC with probability 𝑝 = 𝑘 / 𝑁 . Compared with the threshold method, this policy

generates more accurate traffic information and lowers the communication cost. This

12

method uses Greenshields model to estimate the traffic flow. However, Greenshields model is suitable for highway road segments, but unsuitable for urban roads.

Our TIS design based on the threshold model provides more accurate traffic information for urban roads according to the current trend of the traffic condition trends to reduce the number of reports sent by the probes.

13