Abstract:
Method for determining toll fees for vehicles in a road toll system including vehicle-onboard units and positionally distributed beacons capable of communicating with the onboard units via radio signals. The method includes: providing a toll fee level and a validity time frame; retrieving an identifier of the onboard unit, the toll fee level and the validity time frame from the onboard unit as a data record; resetting the toll fee level, if the validity time frame has expired; increasing the toll fee level and storing the updated data record in the onboard unit and the beacon; transmitting a request for deletion of stored data records for this identifier to other beacons; transmitting the data record from the beacon to the central station, if no deletion request for the data record arrives within the validity time frame; and deleting the data record in the beacon.

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
       [0001]    This application claims priority to European Patent Application No. 11 450 085.3, filed on Jun. 29, 2011, the contents of which are hereby expressly incorporated by reference. 
       FIELD OF THE INVENTION 
       [0002]    The present invention relates to a method for determining toll fees for vehicles in a road toll system comprising vehicle-supported onboard units with a respective unambiguous identifier and positionally distributed beacons with respective known locations, wherein beacons localize passing onboard units to the their beacon location in order to calculate position-related toll fees therefrom, and can communicate with the onboard units via radio. 
       BACKGROUND 
       [0003]    More recent road toll systems locate vehicles, or more precisely the onboard units (OBUs), with the assistance of a network of geographically distributed beacons, e.g. short-range radio beacons. During the passage of an onboard unit, each beacon generates a transaction record for a central accounting station of the road toll system that contains the identifier of the onboard unit and the identifier of the beacon and therefore demonstrates the presence of the vehicle. A debit account of the user can be debited by a location-related roadway, time or regional toll using this data in the central station. Such road toll systems are distinguished by high reliability and a high degree of toll acquisition but could make it possible to trace the movement of the vehicle in the central station, which can be problematic from the point of view of data security. 
       SUMMARY 
       [0004]    In some embodiments, the present invention is a method for determining toll fees for vehicles in a road toll system including vehicle-supported onboard units with respective unambiguous identifiers and positionally distributed beacons with known locations, wherein the beacons localize passing onboard units to their beacon location to calculate position-related toll fees therefrom, and are capable of communicating with the onboard units via radio signals. The method includes: storing a toll fee level and a validity time frame for the toll fee level in a memory in the onboard unit; in a beacon during the passing of the beacon by the onboard unit: retrieving the identifier, the toll fee level and the validity time frame from the memory as a data record; if the validity time frame has expired, resetting the toll fee level; increasing the toll fee level to update the data record and storing the updated data record in the memory of the onboard unit and the beacon; transmitting a request for deletion of stored data records for said identifier to other beacons; if no request for deletion of the stored data record arrives from other beacons during the validity time frame, transmitting the data record from the beacon to the central station; and deleting the data record in the beacon. 
         [0005]    In some embodiments, the beacons are connected to one another via a first network and to a central station of the road toll system via a second one, and the transmitting of the deletion request to the other beacons takes place via the first network and the transmitting of the data record to the central station via the second network. The separation of the networks prevents any monitoring of the data transmission between the beacons by the central station, which further reduces possibilities for abuse. The separation of the networks can be realized logically and/or physically, e.g., by different wire-based data lines, different data channels in a radio network, different radio network technologies or different encryptions. 
         [0006]    In some embodiments, the invention includes the following additional steps: storing a total counter and a section counter in the memory in the onboard unit; in the beacon: retrieving the total counter and the section counter from the onboard unit and placing them in the data record; resetting the section counter when the validity time frame has expired; incrementing the total counter and the section counter when updating the data record, and storing the data record in the onboard unit and the beacon; and, in the central station, if two data records with the same identifier arrive: deleting a data record with a lower total counter, if the difference between the total counters of the two data records is different from the section counter of a data record with a higher total counter. 
         [0007]    With the above embodiments, it is possible to prevent residual errors in certain time constellations, specifically if, due to processing latencies in the beacons or transmission latencies between the beacons, the deletion request arrives slightly too late, for example by milliseconds, at a preceding station so that the latter has already transmitted its record to the central, although the next beacon has taken over the toll fee level. In this case, two overlapping data records regarding the beacons that have been passed could reach the central station, which would lead to billing errors. The evaluation according to the invention of a total and a sectional transaction counter prevents such infrequent latency-induced phenomena. 
         [0008]    In some embodiments, the toll fee level is increased by a fixed value in each case and the section counter can thus be derived from the toll fee level itself, specifically by dividing by the aforementioned fixed value. This makes a special memory area for the section counter superfluous. 
         [0009]    In some embodiments, the toll fee level is increased in each case by a variable value based on measurement data that is measured on a vehicle carrying the onboard unit. This way, a toll fee depending on the dimensions, number of axles, appearance, load, number of passengers, speed, etc., of the vehicle can be charged. 
         [0010]    In some embodiments, which can be used alternatively or additionally, the toll fee level is increased in each case by a variable value that is dependent on stored data read out from the onboard unit. In that way, the onboard unit can contain data for its vehicle such as dimensions, number of axles, ownership, number of passengers etc., which determine the toll fee to be charged. 
         [0011]    In some embodiments, an identifier and a time stamp of the beacon are stored in the onboard unit along with the updated record. This can be logged in the onboard unit as evidence of the transaction process of a beacon and can be read out for enforcement purposes. 
         [0012]    In some embodiments, the identifiers and time stamps of at least those beacons that were passed by an onboard unit since the last reset of the toll fee level are stored in the onboard unit in an encrypted transaction log, which is retrieved from the beacons and sent to the central station when the data record is transmitted. The key for encrypting the transaction protocol is selected, for example, by the user of the onboard unit himself, or is only disclosed to him. The transaction log sent to the central station can be decrypted in case of conflict by the user—and only by the user—for use as proof, which increases the user acceptance without impairing the data protection relative to the central station. 
         [0013]    The method of the present invention is suitable for any type of road toll system with geographically distributed locating beacons, such as beacons that can localize onboard units optically to their station. The method of the present invention is particularly suitable for road toll systems in which the beacons communicate with the passing onboard units via radio connections with limited coverage range and thereby localize the onboard unit to their respective radio coverage range, which results in high reliability. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    The invention will be explained in detail below with reference to embodiment examples illustrated in the attached drawings. In the drawings: 
           [0015]      FIG. 1  schematically shows an exemplary road toll system with a graphical representation of data in the onboard unit at various time points, according to some embodiments of the present invention; 
           [0016]      FIG. 2  shows an exemplary flow diagram in the beacons of a road toll system, according to some embodiments of the present invention; and 
           [0017]      FIG. 3  shows an exemplary flow diagram executed in a exemplary central station of a road toll system, according to some embodiments of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0018]    The present invention creates a secure data protection solution for centrally billed (“postpaid”) onboard units that are located by a distributed beacon network. The toll fee level of an onboard unit is transported with the aid of the onboard unit itself from beacon to beacon and only the respective last beacon in an interrupted chain of successive validity time periods transmits the accumulated toll fee level to the central station. The last beacon in each case is determined automatically from an interruption of the chain of validity time frames. For example, the most recent validity time frame, each beacon stores the previously accumulated toll fee level and, if no deletion request or notification that it has increased the toll fee arrives from a different beacon during this period, then the beacon decides that it is the last of a chain and initiates the transmission of the cumulated toll fee level to the central station. The data records stored in the beacons are thus deleted in every case, either when a deletion request arrives from a different beacon or after expiration of the validity time frame and transmission to the central station. In this manner, the knowledge of position-related individual transactions remains hidden from the central station. 
         [0019]    The validity time frame can be specified or agreed system-wide, or can be individually set by each beacon in order, for example, to take into account the different distances between the beacons. Thus for example, a beacon that is far away from the next one will determine a longer validity time frame and write it in the record of the onboard unit, whereas a beacon that is a short distance away from the next one will set a shorter validity time frame. 
         [0020]    The validity time frames are selected in such a manner that, with an average travel speed of a vehicle from one beacon to the next one, the validity time frame of the most recent toll fee level has not yet expired, when the onboard unit reaches the next beacon. Thus, an expiration of the validity time frame, i.e., an interruption of the chain and therefore transmission of the toll-fee level to the central station occurs only in exceptional cases, for example, stopping during the trip, turning onto a different street, etc. 
         [0021]    Consequently, only data records containing a toll fee level accumulated over several beacon locations normally arrive in the central station and thus do not allow any precise inferences of the individual beacon locations. As a result, a high data security or confidentiality for the sensitive movement data of the onboard units is achieved while simultaneously maintaining the post-pay billing functionality in the central station. 
         [0022]      FIG. 1  schematically shows an exemplary road toll system  1  that comprises a central station (“central system,” CS)  2  and a plurality of geographically distributed beacons (“roadside equipment,” RSE)  3  that interact with vehicle devices or onboard units (OBUs)  4 . The onboard units  4  are carried in vehicles (not shown) that are moving on a road network  5 . A location-related, time-dependent and/or travel path-dependent toll fee for the vehicles is determined with the aid of the beacons  3  and the onboard units  4  and is charged in the central station  2 . 
         [0023]    For this purpose, each beacon  3  can localize a passing onboard unit  4  to its beacon location p, specifically by setting up a radio connection  6  with the onboard unit  4  using a radio coverage range  7  limited to the beacon location p. A successfully set up radio connection  6  shows the presence of the onboard unit  4  in the radio coverage range  7  and thus at the beacon location p. 
         [0024]    In some embodiments, the radio connection  6  is established according to the dedicated short range communication (CEN DSRC) standard, wireless access in a vehicle environment (IEEE WAVE) standard, or the ETSI ITS-G5 standard. In place of a radio connection  6 , a different wireless short-range connection could also be used, for example an infrared connection, ultrasound connection, etc. can be used to establish the connection  6 . 
         [0025]    In some embodiments, during the passage of an onboard unit  4  in conventional road toll systems, each beacon  3 , hereinafter also referred to in general as RSE n  (n=1, 2, 3, . . . ), generates a transaction data record Rec n  for the central station  2  that contains at least an identifier of the onboard unit  4  and an identifier of the beacon  3 , from which, with knowledge of the beacon locations p, the position usages of the onboard unit  4  can be charged in the central station  2 . The method of the present invention described below is used to prevent the path of an onboard unit  4  on the road network  5  from being tracked. 
         [0026]    The radio beacons  3  are connected to one another via a first network  8 , e.g., a local area network (LAN) or wide area network (WAN), either wireless or wire-based. Each beacon  3  can also store transaction data records Rec n  at the central station  2  via a second network  9  separate from the first network  8 . The second network  9  can likewise be a LAN or WAN, either wireless or wire-based. In some embodiments, the first and second networks  8 ,  9  can be connected via one and the same physical network, for example, the Internet, a cellular radio network, a dedicated fiber optic network, etc. The first and second network  8  and  9  are merely logically separated from one another, for example by mutually isolated virtual private networks (VPNs), so far as the central station  2  cannot monitor the data connections of the beacons  3  among one another, i.e., in the first network  8 . 
         [0027]    In the individual onboard units  4 , memories  10  are set up whose contents are schematically illustrated in the lower half of  FIG. 1  at different points in time, in each case immediately after passage of a beacon  3  or RSE n  along the road network  5 . The memory  10  of each onboard unit  4  contains at least one toll fee level ATD (“aggregated total debt”) and one validity time frame VT (“validity time”), as well as optionally a total counter TC (“transaction counter”) and a section counter tc. Another area  10 ′ of the memory  10  can contain semipermanent data such as the identifier id of the onboard unit  4  and vehicle or user specific additional data d, for example. 
         [0028]    At the beginning of the method, e.g., at the initial delivery of the onboard unit  4 , the toll fee level ATD, the total counter TC, the section counter tc and the validity time frame VT are all set to zero. 
         [0029]      FIG. 2  shows an exemplary method that is executed in each beacon  3 , here RSE n+1  for illustrative purposes when an onboard unit  4  passes, i.e., enters its radio coverage range  7  and temporarily sets up a radio connection  6  with the beacon.  FIG. 2  shows the part of the communication protocol for the radio connection  6  that is relevant to the present method. Known communication steps such as handshaking, transmission of checksums and acknowledgments are not shown for simplicity purpose. 
         [0030]    In block  11 , the contents of the memory  10  of a passing onboard unit  4  are read out by the beacon RSE n+1 , for example, the identifier id of the onboard unit  4 , the most recently stored toll fee level ATD n  and its validity time frame VT n . In some embodiments, the most recent total and section counters TC n , tc n  can also be read out as described later with reference to  FIG. 3 . However, in a simplified embodiment, the references below to the total and section counters TC, tc can be omitted. Moreover, the additional data d can optionally be omitted. The read-out data {id, TC n , tc n , ATD n , VT n , d} is compiled in the beacon RSE n+1  into a data record Rec n . 
         [0031]    In block  12 , it is checked whether the read-out validity time frame VT n  has expired or run out. This can be realized in various manners. For example, the value VT n  can indicate an absolute final point in time that can be compared to the current clock time, or it can comprise a starting time point and the length of the validity time window, for example 5 minutes. The validity time frame VT n  indicates the time for which the read-out toll fee level ATD n  is “still valid.” If the validity time frame VT n  has run out (branch “y”), the decision of block  12  branches to a block  13 , in which both the toll fee level ATD n  and the optional section counter tc n  are reset to 0. In the other case (branch “n”), block  13  is skipped and control proceeds directly to block  14 . 
         [0032]    In some embodiments, the following updates are undertaken in block  14 :
       the toll fee level ATD n  is increased by a value CHRG that corresponds to a toll fee for the use of the location p of the beacon RSE n+1 , in order to generate an updated toll fee level ATD n+1 . The value CHRG can be a fixed predetermined value or a variable value determined based on various criteria, e.g., the beacon location P in the memory data d read out of the onboard unit  4 , which can indicate the vehicle class, the dimensions, the weight, the load or the number of passengers, etc., of the vehicle carrying the onboard unit  4 . Furthermore, the volume CHRG can be based on measurement data obtained by the beacon RSE n+1  from the onboard unit  4  or its vehicle, such as its dimensions, appearance (class), weight, speed, number of passengers, etc.;   the optional total counter TC n  is incremented in order to generate an updated total counter TC n+1 ;   the optional section counter tc n  is incremented in order to generate an updated section counter tc n+1 ; and   the validity time frame VT n+1  can (optionally) be determined again, e.g. based on the beacon location, on measured values of the vehicle as mentioned above, on read-out memory data d from the onboard unit  4 , etc.       
 
         [0037]    An updated data record Rec n+1  is obtained at the end of block  14 . 
         [0038]    In blocks  15  and  16 , which can be performed in an arbitrary order or in parallel, the updated data record Rec n+1  is written back into the onboard unit  4  via the radio connection  6  (block  15 ) and is stored in the beacon RSE n+1  (block  16 ). Thereby the new toll fee level ATD n+1  is secured in two ways, in the onboard units  4 , and (temporarily) in the beacon  3  or RSE n+1 . 
         [0039]    In block  17 , a deletion request delReq can be sent by the first data network  8  to all other beacons  3 , or at least to the immediately preceding beacons  3  in the road network  5 , indicating the identifier of the onboard unit  4 , to delete all data records Rec (id) still stored in these beacons  3 . How these beacons  3  proceed with such a deletion request can be immediately explained with reference to the present beacon RSE n+1 , because it now also waits for such a deletion request from other beacons. The method now transitions into a waiting state  18  in which the beacon waits for the arrival of a deletion request delReq (19), but only until the validity time frame VT n+1  expires. In other words, the waiting state  18  terminates by expiration of the validity time frame VT n+1  or by the arrival of a deletion request delReq. 
         [0040]    If no deletion request delReq arrives, i.e., the validity time frame VT n+1  simply expires, the updated data record Rec n+1  is transmitted in a block  20  via the second data network  9  to the central station  2 . If a deletion request delReq is received within the validity time frame VT n+1 , however, block  20  is skipped and there is a branch directly to block  21  of the method. 
         [0041]    In block  21 , the data record Rec n+1  stored in the beacon  3  is deleted. The method in a beacon  3 , explained here for representative purposes with reference to the beacon RSE n+1 , is therefore terminated. The method is executed again at each passage of a beacon  3  by an onboard unit  4 . 
         [0042]    Accordingly, the successive passes of an onboard unit  4  past successive beacons  3  ( . . . RSE n+1 , RSE n , RSE n+1  . . . ) yield the schematically shown values or “fill levels” shown at the bottom of  FIG. 1  for the toll fee level ATD, the total counter TC and the section counter tc during the respective validity time frame VT. As can be seen from  FIG. 1 , if the validity time frame VT for a beacon passage has not yet expired, the toll fee level and the total and section counters Tc, tc are incremented; see the first three beacon passages. At the fourth beacon passage, at beacon RSE n+1 , the preceding validity time frame VT n  had already expired, so that the toll fee level ATD and the section counter tc were reset. At the same time, the waiting time VT n  in the preceding beacon RSE n  in the waiting state  18  had already expired, so that the beacon RSE n  sends its data record Rec n  to the central station  2  (block  20 ). The transmitted data record Rec n  contains a toll fee level ATD accumulated over three beacon passages, which no longer allows any inferences of the individual beacons  3  and therefore the locations p, so that positional anonymity is achieved by section-by-section accumulation. 
         [0043]    In very infrequent time constellations, due to the latency of the data processing in the beacons  3  or the latency of the data transmission between the beacons  3 , it is possible that the deletion request delReq transmitted from a subsequent beacon RSE b  arrives too late in one of the preceding beacons RSE a  to suppress transmission of the data record there, even though the subsequent beacon RSE b  assessed the validity time frame VT 0  as not having elapsed and increased the toll fee level ATD. Optional embodiments of the invention described with reference to  FIG. 3  is used to prevent such latency-induced errors. 
         [0044]      FIG. 3  shows a portion of the method that runs in a central station and evaluates the total counter TC and the section counter tc to take latency-induced double transmissions of data records Rec a , Rec b  into account. If two data records Rec a , Rec b  with one and the same identifier id arrive at the central station  2  (blocks  22  and  23 ), then there is a check in a decision block  24  of whether the difference TC b -TC a  of the total counters for the two data records Rec a , Rec b  corresponds to the section counter tc b  of the second data record Rec b , i.e., the data record with the higher total counter TC b . If yes (branch “y”), then everything is in order and both data records Rec a , Rec b  can be processed in the central station  2 , see blocks  25  and  26 . If no (branch “n”), then there is an overlapping or double transmission, the data record Rec a  with the lower total counter TC a  is deleted (block  27 ) and only the second data record Rec b  is processed (block  28 ). 
         [0045]    If the value CHRG by which the toll fee level ATD is raised in each block is a fixed predetermined value, it is possible to forgo the separate formation of the section counter tc, because the section-by-section number tc of transactions can be directly derived from the toll fee level ATD, divided by the above-mentioned fixed value. 
         [0046]    In block  15 , an identifier of the beacon  3  and the current time stamp can be saved in the onboard unit  4  as evidence. In particular, the evidence is stored in the onboard unit  4  in the form of an encrypted transaction log. The key for encrypting the transaction log is selected, for example, by the user of the onboard unit  4  himself, or is only disclosed to him. The transaction log can be read out from an onboard unit  4  in block  11  and sent in block  20  to the central station  2 , so that encrypted transaction protocols are collected there, which can only be read out as evidence by the respective owner using his key. 
         [0047]    In some embodiments, the radio connections  6 , in particular all the transmission and reception blocks  11 ,  15 ,  20 ,  22 ,  23  shown in  FIGS. 2 and 3 , are encrypted and/or furnished with electronic signatures of the onboard unit  4 , or the beacon  3  to increase the transaction security. 
         [0048]    It will be recognized by those skilled in the art that various modifications may be made to the illustrated and other embodiments of the invention described above, without departing from the broad inventive scope thereof. It will be understood therefore that the invention is not limited to the particular embodiments or arrangements disclosed, but is rather intended to cover any changes, adaptations or modifications which are within the scope and spirit of the invention as defined by the appended claims.