Accurate mobile traffic information acquisition with minimal transmission cost and optional V2V extension

Abstract

A system, includes at least one traffic server to receive traffic information reports transmitted from vehicles located on a traffic network serviced by said at least one traffic server, said traffic network being segmented into a plurality of predefined links, each predefined link associated with a priority level, a reporting latency, and an identification code.

Description

BACKGROUND

The present invention relates to traffic information collection, and more specifically, to reducing cost of transmitting accurate, real-time traffic data to a central server via a cellular network, by using data aggregation, based on quantum transmission cost, and a form of random sampling that is based on priorities of the traffic network links, to determine whether a specific data packet is to be transmitted.

FIG. 1 demonstrates two relatively recent communications systems for vehicles on roadways, typically with at least some aspects still under development. A first communication system permits individual vehicles 102 to transmit data to a central server 104 via a backhaul, such as a cellular network 106, using On Board Units (OBUs) 108 or other equivalent devices.

Collecting traffic data in this manner is not new, since Intelligent Transport Systems (ITS) have been in various stages of development and implementation in various countries. Such traffic information systems are typically based on a plug-and-play, in-vehicle platform utilizing OBUs 108 that link vehicles with the transportation infrastructure 104 using cellular links 110. Some ITS systems permit a two-way transmission by which vehicles can receive information, typically used conventionally for such features as providing safety warnings and traffic information to drivers. In a preferred exemplary embodiment of the present invention, the OBU is capable of Global Positioning System (GPS) interface, to determine the current location of the vehicle in which the OBU is installed.

A second recent vehicular communication system depicted in FIG. 1 is the vehicle-to-vehicle (V2V) intercommunication system 112.This V2V system permits vehicles to “talk” to each other and has been under development for several years by various automobile manufacturer. In some versions, V2V permits ad hoc networks to form among vehicles, as intended to help drivers overcome blind spots, avoid accidents, etc. A V2V standard is close to being approved in the United States, with discussion to make it mandatory by 2017.

The basic approach of acquiring traffic information via technologies such as ITS has been considered as attractive compared to other alternatives, due to its flexibility and potentially very wide coverage with essentially no additional infrastructure requirement.

However, the present inventors have recognized that potentially high cost can be incurred in the conventional ITS-like systems due to the following challenges:

Sufficient amount of data needs to be collected such that the traffic information derived on the central server achieves the required accuracy and network coverage.

The collected traffic data must be transmitted to the server with low latency, such that the derived traffic information satisfies a given real-time requirement.

Each cellular transmission is charged based on a minimum charging unit (e.g. $x per y-KB). To minimize cost, it would be ideal if each OBU would transmit collected data in batches, aligning the batch size with the minimum charging unit. However, waiting for a full batch of data may result in excessive delay, affecting the real-time requirements.

The present invention provides a solution to these newly-recognized problems recognized as due to conflicting aspects in making network traffic data reports in management systems using reports from vehicles.

SUMMARY

According to embodiments of the present invention, a new scheme for cost-effective acquisition of accurate real-time vehicle traffic information by vehicular communications systems is provided, using a new combination of elements having several novel aspects and elements, including aspects of reducing data content of the data transmissions from vehicles, reducing the number of transmissions from vehicles, and aggregating data for each transmission.

The present invention can be demonstrated as reducing the cost of transmitting such network traffic data on a cellular network by using a reduced number of transmissions, as achieved by using a random number generator output value to determine whether a specific data packet will be transmitted at its predetermined reporting time.

Cost is further reduced by using a data aggregation mechanism to accumulate a preset amount of data for each transmission that does occur. In one exemplary embodiment, data aggregation can also optionally include data collected from other vehicles, using a novel application of vehicle-to-vehicle V2V intercommunication.

Although the present invention builds upon traffic reporting systems currently under development, it provides a new, more efficient method to acquire traffic data in a central server(s), as demonstrated by mathematical modeling of the method, as described in some detail herein but as further described in a technical paper to be published shortly by the present inventors. The benefit of this new method is demonstrated by simulation testing relative to known baseline methods currently used or under development.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 exemplarily illustrates traffic data collection 100 via OBUs and the technique of V2V intercommunication;

FIG. 2 illustrates in flowchart format 200 an example of the priority-based sampling method in the OBU of the present invention;

FIG. 3 illustrates an exemplary method 300 of geo-fencing for determining on which link of a network a vehicle is currently located;

FIG. 4 illustrates an exemplary priority table 400 used to set a probability level in the test for whether a transmission from an OBU should occur to the traffic control center server;

FIG. 5 illustrates adding a packet to a transmission queue 500 of an OBU in a vehicle;

FIG. 6 illustrates in flowchart format 600 an exemplary method of testing for transmission of packets;

FIG. 7 shows an exemplary probability function 700 of the sampling probability for 150 OBUs; and

FIG. 8 shows an exemplary application of a V2V method 800 as optionally implemented in accordance with concepts of the present invention.

DETAILED DESCRIPTION

With reference again to FIG. 1, in an exemplary embodiment, the present invention modifies this OBU-based system 100 to incorporate random sampling and data aggregation in a novel way to minimize transmission cost while achieving a given accuracy requirement in the acquired traffic information including, for example, average speed and volume.

The present invention thereby provides a scheme that addresses the newly-recognized, above-described challenges by employing the following exemplary ideas:

Adaptive random sampling: The present invention achieves a target sampling rate that can be adjusted depending on traffic load and accuracy requirements.

Prioritization: A priority queue is used to store collected traffic data where different sampling rate and latency requirements can be imposed on different types of links. Cost savings can be achieved by differentiating between key links that have stricter real-time requirement and other links that can tolerate a higher latency.

Data aggregation: Instead of immediate transmission, collected traffic data are stored in the queue and transmitted in batches. The timing and rate of transmission adapt to the desired target sampling rate while satisfying the real-time requirement. The batch size can be adapted to match the batch size of a minimum transmission cost.

V2V extension: An optional extension to the basic concepts of the present invention exploits vehicle-to-vehicle communication capability via technology such as Dedicated Short Range Communications (DSRC), to optionally achieve further cost savings by pooling data from neighboring vehicles. A simple and robust protocol that can be used in conjunction with other V2V communications is described herein.

The present invention provides a unique and systematic integration of the above ideas into a scheme that is easy to implement, with very modest resource requirements, since at least some versions of conventional OBUs can be easily updated with software modifications that implement the methods of the present invention.

Priority Based Sampling

A priority-based sampling technique is incorporated in the network traffic data transmission mechanism of the present invention, as designed to reduce the overall cost of communications through a combination of two schemes: (1) Probabilistic transmissions of samples, and (2) Optimization of buffer queues.

Probabilistic transmission of samples for each vehicle on each link: For every link that the vehicle passes through, the OBU will acquire vehicle and traffic state information such as the time stamp and GPS coordinates. However, if it is desired only to estimate aggregate traffic state information such as average traffic speed, it is not necessary for all vehicles passing through a link to send out the information. Therefore, in the present invention, each vehicle decides whether to transmit its packets via the 4G network with some probability, as will be explained shortly.

Optimization of buffer queues for quantum based cellular charging: For most telecommunications companies, transmission of 4G cellular data is charged according to a quantum, $x per B bits of data. The possible methods of billing for such transmission costs are beyond the scope of the present invention. Sending any data less than B incurs the same charge $x. For example, suppose the charge is $1 per kilobyte of data (B=8000), and the vehicle transmits a packet of size 20 bits only, then the vehicle is still charged at $1 for the packet that was transmitted. On the other hand, if the vehicle transmits 50 packets of size 20 bits each, it will still be charged at $1. The present inventors have recognized that this consideration means that it makes sense for the OBU to collect data up to a 1 KB packet size before transmitting a data packet to the traffic server. On the other hand, the system of the present invention also has to support near real-time output of traffic state information, which implies that data collected at an older period of time may no longer be relevant and optimally would be discarded rather than transmitted.

The present invention provides a mechanism to balance these conflicting requirements of controlling transmission cost while ensuring that sufficient traffic data is transmitted to the traffic center.

Description of the Method Residing on the OBU

Preferably, the priority-based sampling algorithm of the present invention resides on the OBU of each car participating in traffic reporting and the traffic statistics are calculated through the data collected from the vehicles in the back end central server.

FIG. 2 shows an exemplary method 200 used at the OBU, consisting of two parts:

(i) Geo-fencing for location and link determination 202, and

(ii) Transmission Buffer Management 204.

1) Geo-Fencing for Location and Link Determination

This method is used to determine which link the vehicle is currently on and, from the link information, generate a packet for potential transmission to the traffic control center server. Determination of which link the vehicle/OBU is on is done through receiving GPS coordinates of for the vehicle's current location and then comparing the obtained GPS coordinates versus a geo-hashed version of the entire road network 206 stored in the OBU. Storage of the network can be done efficiently through geo-hashing, and is estimated to take no more than two MegaBytes (MB) of space. Even without geo-hashing, as a crude estimate, it can be supposed that each link on the road network is stored using its four GPS coordinates, and every GPS coordinate is stored as a 32 bit floating point number. Then, the storage requirement for a 50,000 link road network works out to 50,000×4×2×32=1.6 MB.

This storage estimate can be further reduced using simple compression schemes. For example, using geo-hashing, the first few digits in the GPS coordinates can be removed, since they will be the same for each city road network. Thus, with a small amount of lossless compression, the size of each packet is estimated to be 20 bytes, and 20 bytes per packet will be assumed for the remainder of this description. Priority table 208 stores values for latency and probabilities for the different links, as will be explained further in the discussion below.

Thus, in the context of one exemplary embodiment of the present invention, the term “link” or “roadway link” or “network link” refers to a section of a roadway in the network as defined by a set of four pre-defined GPS coordinates. This definition of “link” is possible when the OBUs are presumed as GPS-capable, meaning that the OBU uses a GPS processor circuit to determine current location. However, it is noted that the concepts of the present invention would be possible without presuming GPS-capable OBUs, and other methods of determining links would be possible.

FIG. 3 shows an exemplary method 300 of how the geo-fencing is carried out. As demonstrated in FIG. 3, the OBU compares in step 302 the real-time onboard GPS coordinates with the GPS coordinates stored in its road network database. The closest set of GPS coordinates, which indicate the start line, is then selected. The same procedure is done to determine when the OBU has exited the link, by determining the GPS coordinates of the end line.

After geo-fencing is carried out, a packet 304 is generated. In the exemplary embodiment used to explain the present invention, the contents of the packet 304 are at least:

Road link ID: A link identification tag for the link on which the vehicle is currently located;

Entry time, T_E: The time when the OBU enters the link; and

Exit time, T_X: The time when the OBU exits the link.

It should be noted that this basic reporting packet conveys traffic data in a very compact form for a traffic network segmented into predetermined links since it uses the road link ID rather than vehicle GPS coordinates and provides entry/exit times relative to that specific link. Moreover, if links are concatenated in the network, then exit from one link implies entry into an adjacent link.

In one sense, the geo-fencing mechanism of the present invention can be viewed as an extension of the concept of using a sensor to detect vehicles passing through a toll collection point. A more sophisticated toll collection system could rely upon having vehicles equipped with OBUs that are GPS capable. In such toll collection systems, a toll collection point could be identified as GPS coordinates, thereby eliminating the need for structural sensors located at toll collection points.

However, in the present invention, the GPS capability of the OBU in the vehicle is used to determine when the vehicle passes pre-defined link points, as based on GPS coordinates that define links. Therefore, in contrast to the purpose of toll collection, the present invention is using this GPS-based geo-fencing mechanism for the entirely different purpose of reducing transmission cost of providing traffic data to a network traffic center.

Thus, the aim of the geo-fencing mechanism of the present invention is to identify the road link that a vehicle is currently on, as well as the entry and exit times for that link. The geo-fencing mechanism also eliminates the need to store a full map of the traffic network in the OBU since the geo-fencing mechanism merely needs to compare the vehicle's current GPS coordinates with GPS coordinates of network links, to find the closest link and thereby identify which network link the vehicle is on. This geo-fencing mechanism requires less memory than storing a full map in the OBU of the network and is more robust since it can tolerate more GPS error.

It should also be clear of ordinary skill in the art that a “link ID” could be any code that uniquely identifies each network link, including, for example, a simple binary code stored in memory that uniquely identifies each network link. However, other coding mechanism are also possible, such as a code that identifies each network link, possibly as derived from the GPS coordinates of the link. For example, a portion of the GPS coordinates at the midpoint of the link could serve as a link ID or, as suggested in FIG. 3, a geo-hash ID of the link's two entry points.

2) Transmission Buffer Management

Once a packet 304 is generated upon exit from the link after the exit time is known, the packet is sent to a transmission buffer queue for possible later transmission to a central server, as based on a random sampling mechanism to be described shortly. Management of the transmission queue is done through a priority-based scheme that is carried out by assigning a packet latency to each type of link in the network.

This concept of link latency is a novel aspect of the present invention and not described in any current standard related to traffic reporting known to the present inventors. The latency for each type of link depends on: (1) the desired sampling rate (2) the real-time requirement. Its value can range from small (e.g., 30 secs) to large (e.g., 10 minutes). The sections below that provide more details on the underlying mathematics include more details on ways that could be used to assign the latency in view of the real-time requirement for different link types.

Determining whether the packet is transmitted when the latency is reached is done through assigning a probability of transmission to the packet. FIG. 4 shows an example of a priority table 400 (see also label 208FIG. 2) used for assignment for a three tier priority network, key, important and normal.

For the example given in the table 400 of FIG. 4, “key” links refer to links of highest importance to the user/traffic network regulator. These can be the most frequently visited links in the network, or links in key areas of the traffic network, such as links in the central business district area or links on major highways of the city. These links are usually assigned the lowest latency, L₁. Hence, L₁<L₂.

“Important” links refer to links that the user may be interested in, but not as critical for network operations as the key links. “Normal” links are links for which it would be good to have information on, but the user can do without information on these links. Using the example in FIG. 4 as a running example, it will now be explained how the transmission queue is operated.

Parameter Assignment and Queuing Policy

When an OBU passes through a link, a packet is generated. Latency and transmission probability are assigned to the packet based on the link type. For example, if an OBU passes a link at t=0 and the link is a key link, then the latency is L₁ and the transmission probability is p₁. The time to decide whether the packet is transmitted or not, the transmission testing time, is then T₀=0+L₁=L₁. The packet is then added to the transmission queue and the queue is sorted according to the transmission testing time. FIG. 5 shows an example of the packet 502 being added to the transmission queue 500, with two packets 504, 506 with earlier transmission times T_i than this packet, T₋₂<T₋₁<T₀, and the other packets 508, 510, 512 having a later transmission time T_i than T0.

It is noted that T_i is a fixed time in the future that is computed when the vehicle exits a link and generates a packet. Therefore T_i=T_X+L_i where L_i is the latency depending on the link type. All packets in the queue are sorted by T_i, and the ordering can be arbitrary if two packets have the exact same T_i. As an example, suppose the vehicle exits a key link at 3 pm and key links are assigned a latency of 1 minute, then T_i for this particular packet would be 3:01 pm.

Testing of Transmission

When the clock is at T₋₂ (t=T₋₂), the first packet in the queue is tested for transmission. Testing is done by generating a random number X˜Unif[0, 1] and testing if X<p, where, in our three tier priority network, the p corresponds to either p₁ or p₂. In this exemplary embodiment, the normal links are never tested.

If X<p, a transmission is triggered. Otherwise, the packet is dropped from the queue. In the example 500 in FIG. 5, if the first two packets 504, 506 are dropped, then the inserted packet 502 is tested at time T=T₀. If X<p₁, a transmission occurs. Otherwise, the packet is dropped.

The present invention thus provides a random sampling of traffic data packets that could potentially be transmitted to the traffic center, and the random sampling mechanism takes into account the importance of each link in the network by using a probability value assigned from the priority table having different probability values based on the different types of links in the network. It should be clear that the values stored in the priority table would be easily changed, thereby making the number of transmissions for different types of links adaptable based on current conditions.

Number of Packets Transmitted

If a transmission occurs, packets are transmitted up to the 1 KB limit (in this exemplary embodiment), to take advantage of the assumption that transmissions are charged based on a 1 KB quantum, as a non-limiting example. Hence, not only is the packet tested transmitted, other packets further in the queue are also transmitted, up to the 1 KB limit. As the queue is sorted by transmission times, packets with shorter transmission time are assigned for transmission ahead of packets with longer transmission times. Testing and transmission of packets are summarized as shown in the exemplary flowchart 600 in FIG. 6, showing that, in step 602, a random number is generated each time a transmission time is reached, to determine whether a packet is to be transmitted or dropped, in step 604.

Method at the Central Server

The algorithm at the central server estimates the traffic information from the packets received. To illustrate the method, consider the case of estimating the average traffic speed on a road link in a window of length T_w minutes. Let the realtime clock be at t_s. Let T_tol be a predetermined realtime delay tolerance. We are therefore interested in estimating the average speed of all vehicles passing through that particular link between t_s−T_tol−T_w and t_s−T_tol. For realtime estimates T_tol would be set close to 0.

The central server finds all packets with the road link ID and with exit time between t_s−T_tol−T_w and t_s−T_tol. For each packet i, calculate the travel time, T_Travel=T_x−T_E. It can be assumed that the length of the link L_link link is stored in the server. The speed of the vehicle corresponding to packet i is then estimated as S_i=L_link/T_Travel. Assuming there are N packets within the time window, the average speed is computed as Ŝ=Σ_i=1ⁿS_i. If N=0, a default speed estimate is outputted.

OBU Hardware

From the above description, it should be clear that the OBU 108 shown in FIG. 1 could incorporate concepts of the present invention in several different ways. For example, if the OBU is processor-based, as shown exemplarily in FIG. 1, the memory could store an instruction set that would be executed by a processor or microprocessor to implement steps of the invention. If the OBU 108 is a conventional OBU, such update might be achieved by, for example, downloading a set of instructions similar to the manner in which apps are commonly downloaded on portable communication devices such as mobile phones or tablets, perhaps using an I/O section that permits user inputs and provides user display information. The OBU 108 could also be based upon specialized ASIC (application specific integrated circuit) technology, in which a chip is installed that contains circuits/instructions for implementing the present invention.

It is noted that there is no requirement in terms of the number of vehicles that are equipped with OBUs or whether each OBU is running the same version of the software. The parameters in the scheme, such as the sampling rate, can be adapted to the actual number of vehicles equipped with OBU, which can be estimated based on the transmissions received. The OBU software can be updated via any internet connection (cellular/Wi-Fi), or even via V2V communications (through emerging vehicular communications protocol such as dedicated short range communication (DSRC)).

A motivating example underlying aspects of the present invention is the next-generation electronic road pricing (ERP) system in Singapore, where, by law, each vehicle will be equipped with a GPS-enabled transponder (the OBU) for real-time, adaptive road usage pricing (toll collection) and congestion control. The scheme of the present invention leverages on the envisaged widespread availability of GPS-enabled OBUs in vehicles to collect traffic information in a lightweight and cost-effective manner. The use of GPS units in vehicles to perform road pricing and toll collection is gaining in popularity worldwide, not just in Singapore, since similar schemes are being considered in other cities around the world.

Analysis of Sampling Scheme

In this section, an analysis is given of the sampling scheme for estimating the average speed. This analysis sheds light on why significant cost savings can be expected from the method of the present invention. Let S be the true average speed on a link for the time window that we are interested in. The criteria that we will adopt for this analysis is the probability that the estimate differs from the true average by more than 10 km/hr. That is, we wish to have P(|Ŝ−S|>10) to be as small as possible. In our end user's requirements, the following criteria is adopted:P(|Ŝ−S|>10)≤0.15.

Suppose that the vehicles' average speed on the link are distributed according to a distribution F and that M vehicles pass through the link within the given time window. That is, S_i˜F for i ∈ [1:M]. Suppose that the sample (packet) from vehicle i is transmitted with probability p, and that we received N packets, where N follows a Binomial distribution with parameters M and p.

Then, the probability can be computed as

$\begin{array}{c}P\left(\hat{S}-S>10\right)=P\left(\frac{1}{N}\sum _{i=1}^N{S}_i-S>10\right)\\ =\sum _{n=0}^{M}P\left(N-n\right)\\ P\left(\frac{1}{n}\sum _{i=1}^N{S}_i-S>10|N=n\right)\\ =\sum _{n=0}^{M}P\left(N=n\right)P\left(\frac{1}{n}\sum _{i=1}^n{S}_i-S|>10\right),\end{array}$ where the last line follows from the sampling being independent of S_i and the random variables S_i are identically distributed.

Now, the true average is given by averaging all the speeds of the vehicles passing through the link within the given time window. That is, S=Σ_i=1^MS_i/M. However, for large enough M (M>50) and small p (p<0.2), we will approximate this quantity by the mean of the distribution, μ.

Hence, we approximate the probability as

$P\left(\hat{S}-S>10\right)\approx \sum _{n=0}^{M}P\left(N=n\right)P(\frac{1}{n}\sum _{i=1}^n{S}_i-\mu >10)\le P\left(N=0\right)+\sum _{n=1}^{30}P\left(N=n\right)P\left(\frac{1}{n}\sum _{i=1}^n{S}_i-\mu >10\right)+\sum _{n=31}^{M}P\left(N=n\right)P\left(\frac{1}{n}\sum _{i=1}^n{S}_i-\mu >10\right)\le P\left(N=0\right)+\sum _{n=1}^{30}P\left(N=n\right)P\left(\frac{1}{n}\sum _{i=1}^n{S}_i-\mu >10\right)+P\left(N>30\right)\frac{{\sigma }^2}{100\times 30}$ where the last line follows from Cheybyshev's inequality, and we assume that we know the variance σ² of the distribution F.

In practice, the distribution F is unknown and we approximate it by distributions such as uniform or Gaussian. As an illustrative example, suppose the average speed S_i of a specific link is uniformly distributed within the range 30 km/hr to 70 km/hr. FIG. 7 shows the probability as a function 700 of the sampling probability p for M=150.

As can be seen from FIG. 7, one can sample only 25% of the OBUs in order to obtain a performance guarantee of P(|Ŝ−S|>10) being less than 0.15 (15%).

Optimizing the Parameters of the Sampling Scheme

As described in the previous section, depending on the given accuracy requirement, an effective sampling rate r is needed. We aim to achieve this sampling rate while minimizing the overall transmission cost by choosing the right parameters for the sampling scheme. Here, we focus on the scheme with two main types of links: key and non-key (important).

Recall the four parameters of the scheme:

Transmission latency (i.e. wait time) for key links, L₁>0,

Transmission latency (i.e. wait time) for non-key links, L₂>0,

Transmission probability for key links, 0<p₁<1, and

Transmission probability for non-key links, 0<p₂<1.

Naive scheme: Suppose that the needed effective sampling rate for key links and important links are r₁ and r₂ respectively, and that the real-time delay tolerance (T_tol) for each link type is α₁ and α₂, respectively. Then a guaranteed way to achieve these requirements is to set p₁=r₁, p₂=r₂, L₁=α₁ and L2=α₂.

However, this scheme is too conservative since it completely ignores the fact that packet transmissions happen in batches, and not individually. Consequently the overall transmission cost can be much higher than necessary.

Optimized scheme: Instead of the naive scheme, we can optimize the parameters by taking into consideration the traffic pattern in the network.

We assume the following traffic model in the network. As a vehicle travels, the time interval between visits to key or non-key links is exponentially distributed with mean τ. Each visit is a key link with probability q, otherwise it is a non-key link, independent of the type of previously visited link. It is not difficult to show that the time between two visits to key links is also exponentially distributed, with mean

$\frac{\tau }{q}$ and similarly, for non-key links it is exponentially distributed with mean

$\frac{\tau }{1-q}.$ Furthermore, the number of visits to key links in any time interval is independent of the number of visits to non-key links in the same interval, with the respective Poisson rates.

Let C be the expected transmission cost per link visit with respect to the chosen parameters L₁, L₂, p₁ and p₂. Let ρ₁ be the effective sampling rate for key packets and ρ₂ be the effective sampling rate for non-key packets. We aim to solve the following problem:

$\begin{array}{cc}\underset{L_1,L_2,p_1,p_2}{\mathrm{minimize}}C\mathrm{subject}\mathrm{to}{\rho }_1\ge r_1{\rho }_2\ge r_2.& \left(1\right)\end{array}$

We estimate ρ₁ and ρ₂ by considering the expected number of packets dropped and transmitted in each transmission. Let i₁ and i₂ be the number of key and important packets that are dropped before a transmission is triggered. Let j₁ and j₂ be the number of key and important packets that get transmitted in each transmission. Let Δ=L₂−L₁. It can be shown (see section below entitled “Underlying Mathematics”) that,

$E\left(i_1\right)=\frac{1-p_1}{p_1}\left(1-e^{-\frac{p_{1}q\Delta }{\tau }}\right)+\left(\frac{q\left(1-p_1\right)}{p_2\left(1-q\right)+p_{1}q}\right)e^{-p_{1}q\frac{\Delta }{\tau }},E\left(i_2\right)=\frac{\left(1-p_2\right)\left(1-q\right)}{p_2\left(1-q\right)+p_{1}q}{e}^{-p_{1}q\frac{\Delta }{\tau }},E\left(j_1\right)=\frac{{\mathrm{qL}}_1}{\tau }+1-\frac{p_2\left(1-q\right)}{p_2\left(1-q\right)+p_{1}q}{e}^{-\frac{p_{1}q\Delta }{\tau }},\mathrm{and}$ $E\left(j_2\right)=e^{-\frac{p_{1}q\Delta }{\tau }}\frac{p_2\left(1-q\right)}{p_2\left(1-q\right)+p_{1}q}+\frac{1-q}{p_{1}q}\left(1-e^{-\frac{p_{1}q\Delta }{\tau }}\right)+\frac{L_1\left(1-q\right)}{\tau }.$

We can therefore estimate the fraction of key packets that get transmitted by

$\frac{E\left(j_1\right)}{E\left(j_1\right)+E\left(i_1\right)},$ and similarly

$\frac{E\left(j_2\right)}{E\left(j_2\right)+E\left(i_2\right)}$ for non-key packets. These are however not quite the effective transmission rate since a packet that gets transmitted “too late” does not satisfy the real-time requirement and is essentially dropped. We need to further analyze the latency of each transmitted packet.

Let T_w be the length of the data collection window. Let φ1=min{T_w, max{0, T_w+α₁−L₁}}. Assuming that the visits to each link are uniformly distributed within the time period T_w, the probability that a key packet gets transmitted within the real-time tolerance of the window (see section below entitled “Underlying Mathematics”) is given by

$A_1=\frac{{\varphi }_1}{T_w}+\frac{q\left(T_w+{\varphi }_1\right)\left(T_w-{\varphi }_1+2{\alpha }_1\right)}{2T_w\tau E\left(j_1\right)}.$

Let ϕ₂=min{T_w,max{0, T_w+α₂−L₂}} and ϕ₃=min{T_w,max{ϕ₂,T_w+α₂−L₁}}. The probability that an important packet gets transmitted within the real-time tolerance is given by

$A_2=\frac{{\varphi }_2}{T_w}+\frac{\left({\varphi }_3-{\varphi }_2\right)\left(1-q\right)}{T_{w}E\left(j_2\right)}\left(\frac{L_1}{\tau }+\frac{1}{p_{1}q}\right)-\left(e^{-\frac{p_{1}q}{\tau }{\varphi }_3}-e^{-\frac{p_{1}q}{\tau }{\varphi }_2}\right)\frac{\left(1-q\right)\tau }{{T_w\left(p_{1}q\right)}^{2}E\left(j_2\right)}{e}^{-\frac{p_{1}q}{\tau }\left(T_w+{\alpha }_2-L_1\right)}+\frac{\left(1-q\right)\left(T_w-{\varphi }_3\right)\left(T_w-{\varphi }_3+2{\alpha }_2\right)}{2T_w\tau E\left(j_2\right)}.$

We therefore have the following estimate for ρ₁ and ρ₂:

${\rho }_1=A_1\frac{E\left(j_1\right)}{E\left(i_1\right)+E\left(j_1\right)},{\rho }_2=A_2\frac{E\left(j_2\right)}{E\left(i_2\right)+E\left(j_2\right)}.$

The overall cost of transmission can be estimated by looking at the expected number of link visits per transmission, which is given by

$V=E\left(i_1\right)+E\left(i_2\right)+E\left(j_1\right)+E\left(j_2\right)=\frac{L_1}{\tau }+\frac{1-e^{-\frac{p_{1q\Delta }}{\tau }}}{p_{1}q}+\frac{e^{-\frac{p_{1q}}{\tau }\Delta }}{p_{1}q+p_2\left(1-q\right)}.$

The number of transmissions triggered per link visit is approximately

$\frac{1}{V}.$ Recall that 4 G transmissions are charged by a provider-defined unit. Let b be the number of data packets that fit in one charge unit, and let k be the total number of key and non-key packets in a transmission. Assuming that all packets in the queue are transmitted, then the expected number of 4 G units per transmission is given by

$E=\sum _{i=1}^{\infty }i\mathrm{Pr}\left[\left(i-1\right)b<k\le \mathrm{ib}\right]=1+\sum _{i=1}^{\infty }\mathrm{Pr}\left(k>\mathrm{ib}\right)$ which can be easily computed since k has a Poisson distribution with mean

$\frac{{\mathrm{qL}}_1+\left(1-q\right)L_2}{\tau }.$

Therefore, we have

$C=\frac{E}{V}.$

Analytical solution to the optimization problem (1) can be complicated. Instead, we can obtain an approximate solution by a simple grid search over the 4-dimensional parameter space L₁, L₂, p₁ and p₂.

That is, although an accurate solution would be possible using any of various optimization algorithms, a systematic grid search is the simplest approach and can find a sufficiently good solution in the matter of minutes. There is no need to insist on an accurate solution since the model and its parameters are only approximates of the real traffic pattern, so a coarse grid can be used. Furthermore, the gradient can be exploited to reduce the search time to just seconds, even though the problem itself is not convex.

Baseline Scheme

For the purpose of comparison we introduce a baseline scheme where transmissions happen at a fixed rate, with respect to a chosen fixed time interval T_b. All packets collected within the interval will be transmitted at the end of the period. On one hand, T_b should be chosen large enough such that the expected number of packets is as close to the transmission charge unit as possible. On the other hand, for large T_b some packets may arrive too late, depending on the delay tolerance α₁ and α₂. Let ϕ₁=min{T_w,max{0,T_w+α₁−T_b}} and ϕ₂=min{T_w,max{0,T_w+α₂−T_b}}. We can show that the effective sampling rate for the baseline scheme is

$B_1=\frac{{\varphi }_1}{T_w}+\frac{\left(T_w-{\varphi }_1\right)\left(T_w-{\varphi }_1+2{\alpha }_1\right)}{2T_w{T}_b}$ for key links and

$B_2=\frac{{\varphi }_2}{T_w}+\frac{\left(T_w-{\varphi }_2\right)\left(T_w-{\varphi }_2+2{\alpha }_2\right)}{2T_w{T}_b}$ for important links.

The expected transmission cost per link visit for the baseline scheme is given by

$C_b=\frac{E_b}{V_b}\mathrm{where}{V}_b=\frac{T_b}{\tau }\mathrm{and}$ $E_b=1+\sum _{i=1}^{\infty }\mathrm{Pr}\left(k>\mathrm{ib}\right),k•\mathrm{Poisson}\left(\frac{T_b}{\tau }\right)$

The optimal T_b is thus selected by solving the following:

$\underset{T_b}{\mathrm{minimize}}{C}_b$ $\mathrm{subject}\mathrm{to}{B}_1\ge r_1$ $B_2\ge r_2.$

Numerical Simulations

The performance of the techniques described above was evaluated on simulated traffic data based on a section of the actual road network in Singapore. The map for this simulation consisted of about 9000 links, each with a pre-defined speed limit. Vehicles enter the map via randomly selected points and would use the shortest path to reach a randomly selected destination. The speed of each vehicle on a link is bounded within the range [0.5s, 1.1s] where s is the speed limit of the particular link. Furthermore, the individual vehicle speed is subject to random but gradual changes throughout its journey. Key and important links are selected randomly from the set of most frequently visited links.

Details of this simulation and the results are not provided herein although additional details and results of this form of testing are available in the technical paper to be shortly published by the present inventors.

This testing demonstrated substantial cost savings were indeed achieved by the techniques of the present invention, relative to the existing standard solutions for traffic data reporting, considered to be the baseline for the comparison testing.

More specifically, in terms of transmission cost, the present invention consistently outperformed the baseline, while achieving similar error rates, for both speed and volume estimation. This testing also revealed that additional cost saving is achieved due to the ability to transmit less redundant data on important links.

Transmission Pooling with V2V

Further savings in transmission cost can be achieved by enabling the pooling of data via vehicle-to-vehicle (V2V) communications. This is done by enabling communication between vehicles/OBUs on the road through Dedicated Short Range Radio Communications (DSRC) protocol. V2V communications allows an OBU to aggregate packets from neighboring OBUs for transmission. Data aggregation is useful when the number of packets generated by an OBU is less than the 1 KB quantum that we assumed for charging. In that case, the OBU can increase the utilization of the 1 KB bandwidth by pooling packets from nearby OBUs for transmission.

Our V2V scheme sits on top of our priority based sampling scheme and works on a listener and broadcaster basis. The overall scheme 800 is shown in FIG. 8, and the rest of this section describes the role of the broadcaster and the listener performed by individual OBUs. For this paper, we will not go into details of the DSRC protocol as most the details are not relevant to our scheme. It suffices for our purposes to be aware that DSRC enables V2V communications on the order of 100s of KBs over a range of about 100-200 meters.

Listener: The listener is the default mode in the V2V scheme. In this mode, the OBU listens periodically for a SEND signal from neighboring vehicles. If a SEND signal is found, the listening OBU will transmit its transmission buffer queue, up to 1 KB, to the OBU that transmitted the SEND signal. It then starts a countdown clock with a pre-defined time window and waits for an acknowledgment signal, ACK, from the receiving OBU that its packets have been received. The listener updates its queue by removing all the transmitted packets if an ACK is received. If an ACK is not received in the pre-defined time window, the listening OBU assumes that the transmission has failed and do not delete any packets.

Broadcaster: The second role of an OBU is that of a broadcaster. This role is activated when the OBU is about to transmit its packets. Before transmission, the OBU first checks its transmission buffer. If there are 1 KB (50 packets, assuming 20 bytes per packet) or more of data in the transmission buffer, the OBU simply sends the packets summing up to the first 1 KB. If the total number of bits in the transmission buffer queue is less than 1 KB, the OBU then broadcasts a SEND signal to neighboring OBUs. The broadcasting OBU then waits for a pre-defined time window for other OBUs to transmit their packets to it. If packets are received from another OBU, the broadcasting OBU sends out an ACK to the transmitting OBU and updates its transmission buffer queue. The received packets are inserted into the transmission buffer queue according to transmission as described in the non-V2V setup. This step is carried out for every neighboring OBU that the broadcasting OBU receives its packets from. After the predefined time window is reached, the broadcasting OBU transmits either all the packets in its transmission buffer queue, or up to the first 1 KB, whichever is smaller.

It is noted that the V2V protocol depicted in the flow-chart of FIG. 8 is a completely novel application of conventional V2V protocols. This new protocol in FIG. 8 requires a broadcast capability, which is present in existing technologies such as DSRC. As noted previously, the current focus of V2V communications is mostly on safety-related applications. The present invention uses V2V for the entirely different purpose of improving the cost-effectiveness of traffic data acquisition in an ITS-like traffic system.

Sampling Scheme for V2V

Choosing the optimal parameters for V2V can be more challenging especially when multiple priority queues are used. Here, we focus on the simplest case of a single queue, and without any RSUs in the network. In particular, only traffic data on key links have real-time requirements, packets on all other links can still be transmitted but they are not subject to any accuracy or latency requirements.

We model the effect of V2V by adding an additional parameter no, which is the expected number of neighbors at the time of a transmission broadcast. Furthermore, we assume that the queue length in each neighbor is independent and uniformly distributed.

The two parameters are the wait time L and transmission probability p. We assume that the time between two key-link visits is exponentially distribution with mean τ. The expected number of packets dropped before each transmission can be approximated by

$E\left(i\right)=\frac{1-p}{p}.$

The expected number of packets transmitted in each transmission is approximately

$E\left(j\right)=1+\frac{L}{\tau }\left(1+\frac{n_0}{2}\right).$

Let ϕ=min{T_w,max{0,T_w+α₁−L}}. The probability that a transmitted packet is within the real-time acceptance threshold is approximately

$A=\frac{\varphi }{T_w}+\frac{\left(1+n_0\right)\left(T_w-\varphi \right)\left(T_w-\varphi +2{\alpha }_1\right)}{2\tau T_{w}E\left(j\right)}+\frac{n_0\left({\alpha }_1^3-{\left(T_w-\varphi +{\alpha }_1\right)}^3\right)}{6\tau T_w\mathrm{LE}\left(j\right)}.$

The effective transmission rate is approximately

$\rho =A\frac{E\left(j\right)}{E\left(i\right)+E\left(j\right)}.$

Assuming that all packets in the neighborhood are transmitted, the expected number of 4 G units is approximately

$E=1+\sum _{i=1}^{\infty }\mathrm{Pr}\left(k>\mathrm{ib}\right),k•\mathrm{Poisson}\left(\frac{L}{\tau }\left(1+\frac{n_0}{2}\right)\right).$

The optimal parameters are thus selected by solving the following:

$\underset{L,p}{\mathrm{minimize}}\frac{E}{E\left(i\right)+E\left(j\right)}$ $\mathrm{subject}\mathrm{to}\rho \ge r_1.$

Numerical Simulations

Similar to the testing summarized above for the exemplary embodiment of using a random number generator and basic data aggregation to achieve cost savings, the exemplary embodiment of adding V2V capability to further aggregate data for traffic report transmissions was also tested using numerical simulation. This testing demonstrated that the cost savings can be even more significant when using the V2V option.

Mathematics Underlying the Present Invention

For completeness, the following section provides additional details of the mathematics underlying the present invention.

A. Traffic Model

We assume that traffic data is collected on two types of links with different priorities: key and non-key. All other links are ignored. As a vehicle travels, the time interval between visits to key or non-key links is exponentially distributed with mean τ. In the simplest model, each visit is a key link with probability q, otherwise it is a non-key link, independent of the type of previously visited link. It is not difficult to show that the time between two visits to key links is also exponentially distributed, with mean τ/q and similarly, for non-key links it is exponentially distributed with mean τ/(1−q). Furthermore, the number of visits to key links in any time interval is independent of the number of visits to non-key links in the same interval, with the respective Poisson rates.

The four parameters of the algorithm are:

Transmission latency (i.e. wait time) for key links, L₁>0,

Transmission latency (i.e. wait time) for non-key links, L₂>0,

Transmission probability for key links, 0≤p₁≤1, and

Transmission probability for non-key links, 0≤p₂≤1.

We refer to packets corresponding to key links (resp. non-key links) as key packets (resp. non-key packets). By definition, key packets have shorter transmission latency. We therefore assume that L₁≤L₂. This is without loss of generality since the label key and non-key can simply be swapped should we require that L₁>L₂.

B. Packet Drop Probability

Consider a sequence of packets beginning at time t=0 until the first transmission. We now derive the probability of dropping i₁ key packets and i₂ non-key packets before the first transmission, for i₁=0, 1, 2, . . . and i₂=0, 1, 2, . . . . Denote T as a random variable corresponding to the arrival time of the first transmitted packet. Denote K=1 the event that the first transmission is due to a key packet, and K=0 if it is due to a non-key packet. We are interested in the joint distribution Pr(i₁, i₂, K, T).

We split this into three cases. Case 1 happens when the first transmission occurs at time t<L2. This can only happen when the transmitted packet is a key packet since the earliest possible transmission for a non-key packet is L2. Let Δ=L2−L1. Case 1 therefore corresponds to K=1 and T<Δ.

In this case, all packets dropped must be key packets and arrive before t=T. The arrival time for the (i₁+1)-th key packet has distribution Gamma(i₁+1, τq). We therefore have

$\begin{array}{cc}\begin{array}{c}\mathrm{Pr}\left(i_1,i_2=0,K=1,T<△\right)={\left(1-p_1\right)}^{i_1}{p}_1{\int }_0^{\Delta }\frac{{\left(\frac{\mathrm{qT}}{\tau }\right)}^{i_1}{e}^{-\frac{\mathrm{qT}}{\tau }}}{\frac{\tau }{q}{i}_1!}\mathrm{dT}\\ =\frac{{\left[\left(1-p_1\right)q\right]}^{i_1}{p}_{1}q}{i_1!\tau }{e}^{-\frac{L1}{\tau 0}}{\int }_0^{\Delta }{\left(\frac{T}{\tau }\right)}^{i_1}{e}^{-\frac{\mathrm{qT}}{\tau }}\mathrm{dT}\end{array}& \left(2\right)\end{array}$ Note that Pr(i₁,i₂=0, K=1,T<Δ)=0 for all i₁.

Case 2 happens when the first transmission occurs after t=L2 and is due to a key packet, i.e. K=1 and T≥Δ. In this case, all key packets that arrive before t=T are dropped. For non-key packets, only those that arrive before t=T−Δ will have been tested and dropped. We therefore have that,

$\begin{array}{cc}\mathrm{Pr}\left(i_1,i_2,K=1,T\ge \Delta \right)={\left(1-p_1\right)}^{i_1}{\left(1-p_2\right)}^{i_2}{p}_1{\int }_{△}^{\infty }\frac{{\left(\frac{\mathrm{qT}}{\tau }\right)}^{i_1}{e}^{-\frac{\mathrm{qT}}{\tau }}}{i_1!\frac{\tau }{q}}\frac{{\left(\frac{\left(1-q\right)\left(T-\Delta \right)}{\tau }\right)}^{i_2}{e}^{-\frac{\left(1-q\right)\left(T-\Delta \right)}{\tau }}}{i2!}\mathrm{dT}=\frac{{{\left[\left(1-p_1\right)q\right]}^{i_1}\left[\left(1-p_2\right)\left(1-q\right)\right]}^{i_2}{p}_{1}q}{i_1!i_2!\tau }{e}^{\left(1-q\right)\frac{\Delta }{\tau }}{\int }_{\Delta }^{\infty }{\left(\frac{T}{\tau }\right)}^{i_1}{\left(\frac{T-\Delta }{\tau }\right)}^{i_2}{e}^{-\frac{T}{\tau }}\mathrm{dT}& \left(3\right)\end{array}$

Case 3 happens when the transmission is due to a non-key packet. For this to happen, all non-key packets before t=T must have been dropped. Also, all key packets before t=T+Δ must have been dropped. We therefore have

$\begin{array}{cc}\mathrm{Pr}\left(i_1,i_2,K=0\right)={\left(1-p_1\right)}^{i_1}{\left(1-p_2\right)}^{i_2}{p}_2{\int }_0^{\infty }\frac{{\left(\frac{\left(1-q\right)T}{\tau }\right)}^{i_2}{e}^{-\frac{\left(1-q\right)T}{\tau }}}{i_2!\frac{\tau }{1-q}}\frac{{\left(\frac{q\left(T+\Delta \right)}{\tau }\right)}^{i_1}{e}^{-\frac{q\left(T+\Delta \right)}{\tau }}}{i_1!}\mathrm{dT}=\frac{{{\left[\left(1-p_1\right)q\right]}^{i_1}\left[\left(1-p_2\right)\left(1-q\right)\right]}^{i_2}{p}_2\left(1-q\right)}{i_1!i_2!\tau }{e}^{-q\frac{\Delta }{\tau }}{\int }_0^{\infty }{\left(\frac{T+\Delta }{\tau }\right)}^{i_1}\left(\frac{T}{\tau }\right)e^{-\frac{T}{\tau }}\mathrm{dT}.& \left(4\right)\end{array}$

Adding all three cases, we have that

$\begin{array}{cc}\mathrm{Pr}\left(i_1\right)=\mathrm{Pr}\left(i_1,i_2=0,K=1,T<\Delta \right)+\sum _{i_2=0}^{\infty }\mathrm{Pr}\left(i_1,i_2,K=1,T\ge \Delta \right)+\mathrm{Pr}\left(i_1,i_2,K=0\right)=\frac{{\left[\left(1-p_1\right)q\right]}^{i_1}{p}_{1}q}{i_1!\tau }{e}^{-\frac{L_1}{{\tau }_0}}{\int }_0^{\Delta }{\left(\frac{T}{\tau }\right)}^{i_1}{e}^{-\frac{\mathrm{qT}}{\tau }}\mathrm{dT}+\left(\frac{p_{1}q+p_2\left(1-q\right)}{\tau }\right)\frac{{\left[\left(1-p_1\right)q\right]}^{i_1}}{i_1!}{e}^{\frac{\Delta }{\tau }{p}_2\left(1-q\right)}{\int }_{\Delta }^{\infty }\left(\frac{T}{\tau }\right)e^{-\frac{T}{\tau }\left(p_2+q-p_{2}q\right)}\mathrm{dT}.& \left(5\right)\end{array}$

Similarly, we have

$\begin{array}{cc}\mathrm{Pr}\left(i_2\right)=I\left(i_2=0\right)\left(1-e^{-\frac{p1q\Delta }{\tau }}\right)+\left(\frac{p_{1}q+p_2\left(1-q\right)}{\tau }\right)\frac{{\left[\left(1-p_2\right)\left(1-q\right)\right]}^{i_2}}{i_2!}{e}^{-\frac{\Delta }{\tau }p1q}{\int }_0^{\infty }{\left(\frac{T}{\tau }\right)}^{i_2}{e}^{-\frac{T}{\tau }\left(1-q+p_{1}q\right)}\mathrm{dT}.& \left(6\right)\end{array}$ C. Expected Number of Packets Dropped Per Transmission

With the packet drop probabilities (5) and (6), we can now derive the expected number of packets dropped before the first transmission as follows:

$\begin{array}{cc}E\left(i_1\right)=\sum _{i1=0}^{\infty }{i}_1\mathrm{Pr}\left(i_1\right)=\frac{1-p_1}{p_1}\left(1-e^{-\frac{p_{1}q\Delta }{\tau }}\right)+\left(\frac{q\left(1-p_1\right)}{p_2\left(1-q\right)+p_{1}q}\right)e^{-p_{1}q\frac{\Delta }{\tau }}& \left(7\right)\end{array}$ and similarly

$\begin{array}{cc}E\left(i2\right)=\frac{\left(1-p_2\right)\left(1-q\right)}{p_2\left(1-q\right)+p_{1}q}{e}^{-p_{1}q\frac{\Delta }{\tau }}& \left(8\right)\end{array}$ D. Expected Number of Packets Per Transmission

For simplicity, we assume that all key and non-key packets in the queue will be transmitted whenever a successful transmission happens. Since the number of key packets generated within a time period L₁ is Poisson distributed with mean

$\frac{{\mathrm{qL}}_1}{{\tau }_1},$ the expected number of key packets per transmission is

$1+\frac{{\mathrm{qL}}_1}{{\tau }_1}$ if the transmission is due to a key packet (i.e. K=1). For K=0 the expected number of key packets is

$\frac{{\mathrm{qL}}_1}{{\tau }_1}.$

First, we have that

$\begin{array}{cc}\mathrm{Pr}\left(K=0\right)=\sum _{i_1=0}^{\infty }\sum _{i_2=0}^{\infty }\mathrm{Pr}\left(i_1,i_2,K=0\right)=\frac{p_2\left(1-q\right)}{p_2\left(1-q\right)+p_{1}q}{e}^{-\frac{p_{1}q\Delta }{\tau }}& \left(9\right)\end{array}$

Let j₁ be the number of key packets transmitted. Using (9) we therefore have

$\begin{array}{cc}\begin{array}{c}E\left(j_1\right)=\mathrm{Pr}\left(K=1\right)\left(1+\frac{{\mathrm{qL}}_1}{\tau }\right)+\mathrm{Pr}\left(K=0\right)\frac{{\mathrm{qL}}_1}{\tau }\\ =\frac{{\mathrm{qL}}_1}{\tau }+1-\frac{p_2\left(1-q\right)}{p_2\left(1-q\right)+p_{1}q}{e}^{\frac{p_{1}q\Delta }{\tau }}\end{array}& \left(10\right)\end{array}$

Similarly, let j₂ be the number of non-key packets transmitted. The expected number of non-key packets transmitted in the event K=0 is

$1+\frac{\left(1-q\right)L_2}{\tau }.$ In the event K=1, the expectation is

$\frac{\left(1-q\right)L_2}{\tau }\mathrm{if}T\ge \Delta \mathrm{and}\frac{\left(1-q\right)\left(T+L_1\right)}{\tau }$ if T<Δ. This is due to the fact that in the latter case, the transmission happens at T+L₁<L₂ and only

$\frac{\left(1-q\right)\left(T+L_1\right)}{\tau }$ non-key packets are generated in this period in expectation.

We then have

$\begin{array}{cc}\begin{array}{c}E\left(j_2\right)=\mathrm{Pr}\left(K=0\right)\left(1+\frac{\left(1-q\right)L_2}{\tau }\right)+\mathrm{Pr}\left(K=1,T\ge \Delta \right)\frac{\left(1-q\right)L_2}{\tau }+\\ {\int }_0^{\Delta }\mathrm{Pr}\left(K=0,T\right)\frac{\left(1-q\right)\left(T+L_1\right)}{\tau }\mathrm{dT}\\ =e^{-\frac{p1q\Delta }{\tau }}\frac{p_2\left(1-q\right)}{p_2\left(1-q\right)+p_{1}q}+\frac{1-q}{p_{1}q}\left(1-e^{-\frac{p_{1}q\Delta }{\tau }}\right)+\frac{L_1\left(1-q\right)}{\tau }\end{array}& \left(11\right)\end{array}$ E. Effective Acceptance Rate

Suppose a data collection window has a period T_w, between time t₀ and t₀+T_w. A key packet that is generated at time t ∈ [t₀,t₀+T_w] is accepted if its transmission time happens at some t₁≥t and t₁≤t₀+T_w+α₁, where α₁ is a preset realtime delay tolerance for key packets. Similarly, there is a preset tolerance α₂ for non-key packets. Packets that are transmitted beyond the delay tolerance are essentially discarded.

We assume that packet generation time for any given link is uniformly distributed within any data collection window T_w. Recall that a packet transmission happens when the packet at the top of the queue reaches the preset latency (i.e. wait time), L1 for key packets and L2 for non-key packets.

A key packet that triggers a transmission therefore has a delay of L₁. Suppose this packet arrives at t=T, then all key packets that arrive within time [T, T+L₁] will get transmitted. In particular, a key packet that arrives at t₁ ∈ [T, T−L₁] will have a delay T+L₁−t₁.

Similarly, if the transmission is due to a non-key packet that arrives at t=T, then a key packet that arrives at t₁ ∈ [T+Δ, T+L₂] will get transmitted with delay T+L₂−t₁. For any 0<β<L₁, due to the Poisson arrival rate, the expected number of key packets that get transmitted with delay at most β is therefore qβ/τ. Overall, the expected number of key packets with delay β is qβ/τ. We divide the above by E(j₁) as an approximation for the probability that a transmitted key packet has delay at most β. For a fixed data collection window of size T_w, let φ1=min{T_w, max{0, T_w+α1−L1}}. The probability that a transmitted key packet gets accepted can therefore be approximated by

$A_1=\frac{{\varphi }_1}{T_w}+{\int }_{{\varphi }_1}^{T_w}\left(\frac{1}{T_w}\right)\frac{q\left(T_w+{\alpha }_1-t\right)}{\tau E\left(j_1\right)}\mathrm{dt}=\frac{{\varphi }_1}{T_w}+\frac{q\left(T_w-{\varphi }_1\right)\left(T_w-{\varphi }_1+2{\alpha }_1\right)}{2T_w\tau E\left(j_1\right)}$

Now we look at the delay of transmitted non-key packets. For transmission due to a non-key packet, the expected number of non-key packets with delay at most β for any 0<β<L₂ is given by

$\frac{\left(1-q\right)\beta }{\tau }.$ For transmission due to a key packet that arrives at t=T, the expected number of non-key packets with delay β is

$\frac{\left(1-q\right)\beta }{\tau }$ for β<T+L₁ and

$\frac{\left(1-q\right)\left(T+L_1\right)}{\tau }$ for β>T+L₁.

Combining all cases, the expected number of non-key packets with delay at most β is given by

$E\left[j_2;\beta \right]=\{\begin{array}{c}\frac{\left(1-q\right)\beta }{\tau }\mathrm{if}\beta \le L_1,\\ \frac{\left(1-q\right)L_1}{\tau }+\frac{1-q}{p_{1}q}\left(1-e^{-\frac{p_{1}q\left(\beta -L_1\right)}{\tau }}\right)\mathrm{if}{L}_1<\beta <L_2\end{array}$

The probability that a transmitted non-key packet gets accepted can therefore be approximated by

$\begin{array}{c}{A}_2=\frac{{\varphi }_2}{T_w}+{\int }_{{\varphi }_2}^{{\varphi }_3}\left(\frac{1}{T_w}\right)\frac{E\left[j_2;\beta =T_w+{\alpha }_2-t\right]}{E\left(j_2\right)}\mathrm{dt}+\\ {\int }_{{\varphi }_3}^{T_w}\left(\frac{1}{T_w}\right)\frac{E\left[j_2;\beta =T_w+{\alpha }_2-t\right]}{E\left(j_2\right)}\mathrm{dt}\\ =\frac{{\varphi }_2}{T_w}+\frac{\left({\varphi }_3-{\varphi }_2\right)\left(1-q\right)}{T_{w}E\left(j_2\right)}\left(\frac{L_1}{\tau }+\frac{1}{p_{1}q}\right)-\\ \left(e^{\frac{p_{1}q}{\tau }{\varphi }_3}-e^{\frac{p_{1}q}{\tau }{\varphi }_2}\right)\frac{\left(1-q\right)\tau }{{T_w\left(p_{1}q\right)}^{2}E\left(j_2\right)}{e}^{-\frac{p_{1}q}{\tau }\left(T_w+{\alpha }_2-L_1\right)}+\\ \frac{\left(1-q\right)\left(T_w-{\varphi }_3\right)\left(T_w-{\varphi }_3+2{\alpha }_2\right)}{2T_w\tau E\left(j_2\right)}.\end{array}$

Conclusion

From the description above, it can be seen that the present invention provides a novel solution to the newly-recognized problem of balancing the requirement to report traffic data in an ITS-like traffic reporting system with the cost of transmitting such traffic data. In the system of the present invention, the traffic data is condensed in content by using link identification derived by the technique of geo-fencing. The transmission/buffer management scheme of the present invention combines random sampling of links, identified via geo-fencing, with a priority-based queuing mechanism, to provide a new way in ITS-like traffic reporting systems to answer the questions of “when” to do the sampling test based on probability for determining if/when a report transmission should occur, “what” probability is to be used for the sampling test, and “how much” data to transmit in each data transmission. Existing schemes for data reporting in ITS-like systems are not cost effective in view of the present disclosure.

Although the exemplary embodiments were described as based upon GPS-capable OBUs and links defined as sets of GPS coordinates, the concepts of present invention are not intended as limited to such configuration details. That is, it should be clear that it is possible to implement such concepts as random sampling for determining transmission of data packets, as further based on defining different probabilities for different types of links, of storing and managing data packets for potential transmission in a transmission queue based on priority, of data aggregation for transmissions that do occur as resultant from the random sampling, and of extending V2V capability for data aggregation in traffic data reports in a traffic reporting system that does not use GPS-capable OBUs. Various concepts used in the present invention will operate in any traffic reporting system having a quantum cost of transmission for making traffic reports to a central traffic system.

The descriptions of various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A system, comprising: at least one traffic server to receive traffic information reports transmitted from vehicles located on a traffic network serviced by said at least one traffic server, said traffic network being segmented into a plurality of predefined links, each predefined link associated with a priority level, a reporting latency, and an identification code; andan onboard unit in a vehicle to transmit traffic information reports to said at least one traffic server, said onboard unit configured to report a current location of said vehicle to said at least one traffic server by reporting on which predefined link the vehicle is currently located.

2. The system of claim 1, wherein said onboard unit is configured with a vehicle-to-vehicle (V2V) system and wherein said onboard unit, prior to making a transmission report to said at least one traffic server, communicates using said V2V system to aggregate data for said transmission report with data from one or more other vehicles equipped with said V2V system.

3. The system of claim 1, wherein said onboard unit is configured: to determine a current location of said vehicle;based on said current location, to determine on which of a link of said predefined links in said traffic network said vehicle is currently located;to determine a link identification code that corresponds to said link on which said vehicle is currently located; andto generate a traffic data packet to be potentially transmitted by said onboard unit to said at least one traffic server.

4. The system according to claim 1, wherein each link of said plurality of predefined links is defined as a set of four GPS (Global Positioning System) coordinates, and wherein said onboard unit uses a geo-fencing calculation based on said four GPS coordinates to determine on which link said vehicle is currently located.

5. The system according to claim 1, wherein said traffic data packet further includes an entry time into said link and an exit time from said link.

6. The system according to claim 3, wherein said onboard unit is further configured: to determine a potential transmission time for said traffic data packet to be transmitted to the at least one traffic server, as based on said latency of said identified link;to determine a probability level for the traffic data packet, as based on said priority level of said identified link; andto store said traffic data packet in a transmission queue,wherein traffic data packets are stored in said transmission queue in an ordering of potential transmission times for each stored traffic data packet.

7. The system of claim 6, wherein said onboard unit is further configured: when a current time matches a potential transmission time for one of said traffic data packets stored in said transmission queue, to generate an output from a random number generator having parameters set for a priority level of the identified link associated with the traffic data packet with the potential transmission time;to compare said random number generator output with said probability level for said traffic data packet; and,based on said comparing, either to drop said data packet from said transmission queue or to make a transmission to said at least one traffic server of said traffic data packet along with other traffic data packets stored in said transmission queue up to a transmission length not to exceed a predetermined length based on a quantum charge for transmissions.

8. A method, comprising: in an onboard unit installed in a vehicle, determining that said vehicle has entered onto a link of a plurality of network traffic links;determining an identification of said link;determining an entry time and an exit time of said vehicle for said determined link; andgenerating a traffic data report packet including an identification of said link and said entry and exit times.

9. The method according to claim 8, wherein said onboard unit has a vehicle-to-vehicle (V2V) communication system capability to communicate with onboard units of other vehicles, said method further comprising using said V2V system to aggregate traffic data report packets from at least one other vehicle in said transmission to said traffic center server.

10. The method according to claim 8, wherein said traffic data report packet is assigned a potential transmission time for potentially making a transmission of said traffic data report packet and a probability value assigned to said traffic data report packet as based on a priority of said identified link, said method further comprising: storing said generated traffic data report in a transmission queue along with said assigned potential transmission time and said probability value; andmaintaining said generated traffic data report packet in said transmission queue with other traffic data report packets in a sequence in accordance with potential transmission times of said other traffic data report packets.

11. The method according to claim 8, further comprising: whenever a current time matches a potential transmission time for any of said traffic data report packets stored in said transmission queue, said onboard unit generates an output value from a random number generator having parameters set in accordance with a priority value of a traffic link of said traffic data report packet with said potential transmission time; andbased on a comparison of said generated output value with the probability value assigned to said traffic data report packet, said onboard unit executes one of: drops said traffic data report packet from said transmission queue; andmakes a transmission to a traffic center server via a communication link of said traffic data report packet, said transmission including other traffic data report packets in said transmission queue, up to a preset transmission length based on a quantum cost of transmission via said communication link.

12. The method of claim 8, wherein said potential transmission time is based on a latency assigned to said identified link, based on a priority of said identified link in said traffic network.

13. The method of claim 8, wherein said onboard unit is GPS-capable, wherein each link of said plurality of network traffic links is defined as a set of four global positioning system (GPS) coordinates, and wherein said onboard unit uses a geo-fencing calculation to determine on which link said vehicle is currently located.

14. The method of claim 8, wherein said identified link in said traffic report packet is identified using an identification code.

15. The method of claim 8, as embodied in a set of computer-readable instructions stored in a non-transitory memory device.

16. The method of claim 15, wherein said non-transitory memory device comprises a non-transitory memory device on one of: said onboard unit; anda network server that provides said set of instructions as an update for onboard units located in said traffic network.

17. An apparatus, comprising: a processor;a transceiver; andat least one non-transitory memory device,wherein at least one said non-transitory memory device stores a set of instructions to permit said apparatus to function as an onboard unit on a vehicle by: determining a current location of a vehicle in which said onboard unit is installed;determining, using said current location, that said vehicle has entered onto a specific network link of a plurality of previously-defined network links of a traffic network and identifying a link identification code corresponding to said specific network link;identifying a time of entry into said specific network link and a time of exit from said specific network link; andgenerating a traffic data report packet including said link identification code and said entry and exit times.

18. The apparatus of claim 17, wherein said onboard unit has a vehicle-to-vehicle (V2V) communication system capability to communicate with onboard units of other vehicles, said method further comprising using said V2V system to aggregate traffic data report packets from at least one other vehicle in said transmission to said traffic center server.

19. The apparatus of claim 17, wherein said traffic data report packet is assigned a potential transmission time and a probability value, said potential transmission time and said probability value based on a predefined priority of said specific network link in said traffic network, said set of instruction further permitting said apparatus to store, in a transmission queue, said traffic data report packet along with said assigned potential transmission time and said assigned probability value, wherein said traffic data report packet is stored and maintained in said transmission queue with other traffic data report packets in a sequence according to potential transmission times.

20. The apparatus of claim 18, wherein, whenever a current time matches a potential transmission time of any of said traffic data report packets stored in said transmission queue, said onboard unit generates an output value from a random number generator having parameters set in accordance with a priority value of a traffic link of said traffic data report packet with said potential transmission time; and based on a comparison of said generated output value with the probability value assigned to said traffic data report packet, said onboard unit executes one of: drops said traffic data report packet from said transmission queue; andmakes a transmission to a traffic center server via a communication link of said traffic data report packet, said transmission including other traffic data report packets in said transmission queue, up to a preset transmission length based on a quantum cost of transmission via said communication link.