METHOD AND APPARATUS FOR TRUSTED RECORDING IN A ROAD TOLL SYSTEM

Abstract

A method for trusted recording in a road toll system, the road toll system having a proxy server connected via a mobile network to an onboard-unit of a vehicle, the onboard-unit having a position determination device, comprising: creating an itinerary record comprising a first or second position, a first or second point of time at least one of: a distance calculated using at least the first and second position, a segment-id, and a distance calculated using said segment-id; receiving and recording a signed itinerary record from the proxy server. In a further aspect of the embodiment an onboard-unit and a proxy server are provided for trusted recording in a road toll system.

Claims

1. A method for trusted recording in a road toll system, the road toll system having a proxy server connected via a mobile network to an onboard-unit of a vehicle, the onboard-unit having a position determination device for determining a current position of the vehicle, the onboard-unit having no trusted element, comprising the following steps performed in the onboard-unit: determining a first position by means of the position determination device at a first point of time and a second position by means of the position determination device at a second point of time; creating an itinerary record comprising the first or second position, the corresponding first or second point of time and at least one of: a distance calculated using at least the first and second position, a segment-id calculated using at least the first or second position, and a distance calculated using said segment-id; sending the itinerary record via the mobile network to the proxy server; receiving a signed itinerary record from the proxy server, and recording said signed itinerary record in a memory of the onboard-unit; the method further comprising the step of signing the itinerary record in a trusted element of the proxy server with a digital signature.

2. The method according to claim 1, wherein the signature comprises a sequential identifier.

3. The method according to claim 1, wherein the onboard-unit sends the signed itinerary record to an enforcement terminal which checks said signed itinerary record for plausibility.

4. The method according to claim 1, wherein the following steps are performed in the onboard-unit after determining the first position and before determining the second position: creating a partial itinerary record comprising at least one of the first position and the first point in time; sending the partial itinerary record from the onboard-unit to the proxy server; receiving a signed partial itinerary record via the mobile network from the proxy server; and recording said signed partial itinerary record in a memory of the onboard-unit.

5. The method according to claim 4, comprising the step of signing the partial itinerary record in a trusted element of the proxy server with a digital signature.

6. The method according to claim 4, wherein the onboard-unit sends the signed partial itinerary record to an enforcement terminal, which checks said signed partial itinerary record for plausibility.

7. The method according to claim 4, wherein the partial itinerary record further comprises data of at least one previously recorded signed or unsigned itinerary record and/or at least one previously signed or unsigned partial itinerary record.

8. The method according to claim 6, wherein the onboard unit further sends the signed itinerary record to the enforcement terminal which checks the signed itinerary record for plausibility; and wherein the enforcement terminal checks if the identifier of the signed itinerary record and the identifier of the signed partial itinerary record are in a predetermined sequential relationship.

9. The method according to claim 3, wherein the enforcement terminal compares the signed itinerary record to a signed itinerary record received from the proxy or a central station to which said signed itinerary record had been forwarded by the proxy server.

10. The method according to claim 1, wherein the position determination device is a GNSS receiver.

11. An onboard-unit for mounting on a vehicle in a road toll system, the onboard-unit comprising: a position determination device for determining a current position of the vehicle; a memory; a transceiver for communication with a proxy server via a mobile network; and a processor coupled to the memory, the position determination device and the transceiver; the onboard-unit having no trusted element; wherein the processor is configured to determine a first position by means of the position determination device at a first point of time and a second position by means of the position determination device at a second point of time, create an itinerary record comprising the first or second position, the corresponding first or second point of time and at least one of: a distance calculated using at least the first and second position, a segment-id calculated using at least the first or second position, and a distance calculated using said segment-id, send the itinerary record via the transceiver to the proxy server, receive a signed itinerary record from the proxy server via the transceiver, wherein the itinerary record was signed in a trusted element of the proxy server with a digital signature, and record said signed itinerary record in the memory.

12. The onboard-unit according to claim 11, wherein the processor is further configured to, after determining the first position and before receiving the second position, create a partial itinerary record comprising at least one of the first position and the first point in time, send the partial itinerary record from the onboard-unit to the proxy server via the transceiver, receive a signed partial itinerary record from the proxy server via the transceiver, and record said signed partial itinerary record in the memory.

13. The onboard-unit according to claim 11, comprising a further transceiver for communication with an enforcement terminal, wherein the processor is configured to send the signed itinerary record to the enforcement terminal via the further transceiver.

14. A proxy server for a road toll system, the proxy server comprising a transceiver for communication via a mobile network with an onboard-unit carried by a vehicle); a trusted element; and a processor coupled to the transceiver and the trusted element; wherein the processor is configured to receive, via the transceiver, an itinerary record comprising a first or second position, a corresponding first or second point in time and a distance based on at least the first and second position from the onboard-unit, let the received itinerary record have signed by the trusted element with a digital signature, and send the signed itinerary record from the proxy server via the transceiver to the onboard-unit.

15. The proxy server according to claim 14, wherein the processor is further configured to receive a partial itinerary record comprising at least one of the first position and the first point in time from the onboard-unit via the transceiver, let the received partial itinerary record have signed by the trusted element with a digital signature, and send the signed partial itinerary record from the proxy server via the transceiver to the onboard-unit.

16. The method according to claim 5, wherein the signature comprises a sequential identifier.

17. The method according to claim 8, wherein the enforcement terminal compares the signed itinerary record to a signed itinerary record received from the proxy or a central station to which said signed itinerary record had been forwarded by the proxy server.

18. The onboard-unit according to claim 11, wherein the position determination device is a GNSS receiver.

19. The onboard-unit according to claim 13, wherein the transceiver is a DSRC transceiver.

20. The proxy server according to claim 14, wherein the signature comprises a sequential identifier.

Description

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

[0058] The method and apparatus shall now be explained in more detail below on the basis of exemplary embodiments thereof with reference to the accompanying drawings, in which:

[0059] FIG. 1 shows a schematic overview of a road toll system with components according to an embodiment;

[0060] FIG. 2 shows a block diagram of the components of the road toll system of FIG. 1;

[0061] FIG. 3 shows the method of an embodiment in the form of a sequence diagram.

DETAILED DESCRIPTION

[0062] FIG. 1 shows a road toll system 1 with a road 2 on which a vehicle 3 carrying an onboard-unit (OBU) 4 travels. Vehicles 3 in the road toll system 1 are required to determine their own positions and distances traveled on the roads 2 and to submit this information via a mobile network 5 such as a public land mobile network (PLMN), e.g., GSM, UMTS, LTE, or another 3G/4G/5G network, to a central station 6 for billing, registration, etc.

[0063] To transmit data to the central station 6, the OBU 4 is equipped with a processor 7 (FIG. 2) coupled to a transceiver 8 (with antenna 9) which works according to the standard used in the mobile network 5, e.g., GSM, UMTS, LTE, etc. The transceiver 8 sends data to be transmitted via the mobile network 5 either directly to the central station 6 or to a proxy server 10 which—according to one of its features—forwards the received data via a data network 11, such as the Internet, to the central station 6. To this end, the proxy server 10 is also equipped with a transceiver 12 (with antenna 13) which works according to the standard used in the mobile network 5.

[0064] To gather information about its current position and distance travelled, the OBU 4 comprises a position determination device 14. In the embodiments shown in FIGS. 1 and 2, a global navigation satellite system (GNSS) receiver is used as position determination device 14 by way of which the OBU 4 receives navigation signals 15 of a GNSS 16 such as GPS, GLONASS, GALILEO or the like, and based thereon successively generates readings of its own current position (“position fixes”) p.sub.1, p.sub.2, . . . , generally p.sub.n, at successive points of time t.sub.1, t.sub.2, . . . , generally t.sub.n, which are determined by a time determination device such as the GNSS receiver 14 itself, the processor 7, or a separate clock. Alternatively, the OBU 4 could also determine the current positions in another manner, for example by way of an inertial measurement or dead reckoning system, optical (visual) recognition of landmarks, or by radio triangulation or cell identifier evaluation in the mobile network 5 or a network of radio beacons, e.g., DSRC beacons.

[0065] By means of the position determination device 14, the OBU 4 gathers a set of current positions {p.sub.n}.sub.i, (i=1, 2, . . . ) over a time interval T.sub.i with a predetermined length which in turn defines a section s.sub.i of the road 2 on which the vehicle 3 has travelled during the time interval T.sub.i. Each time interval T.sub.i can be defined by its first point of time t.sub.f,i and its last point of time

[0066] The set of current positions {p.sub.n}.sub.i gathered on the section s.sub.i can be summarised by the first position p.sub.f,i or the last position p.sub.l,i therein and a—roughly approximated or precisely calculated—distance d.sub.i spanned by the set of current positions {p.sub.n}.sub.i reflecting—approximately or precisely—the distance travelled by the vehicle 3 in the section s.sub.i.

[0067] To report its way travelled to the central station 6 in an efficient manner, the OBU 4 creates a so-called itinerary record RC.sub.i for the section s.sub.i. According to the standard CEN TS 16702-1, such itinerary records comprise the last position of a section s.sub.i, the last point of time t.sub.l,i of the section s.sub.i, and the distance d.sub.i travelled within the section s.sub.i, although different representations of the section s.sub.i may be chosen such as, for example, the first position p.sub.f,i first point of time t.sub.f,i and distance d.sub.i, or the first and last positions p.sub.f,i, p.sub.l,i (without time and distance) and/or some of the other current positions p.sub.n of the set of current positions {p.sub.n}.sub.i gathered over the section s.sub.b etc. The OBU 4 is further equipped with a memory 17 to temporarily or permanently store gathered positions p.sub.n, position sets {p.sub.n}.sub.i, itinerary records RC.sub.i, etc.

[0068] Instead of the distance d.sub.i driven on the section s.sub.i, the itinerary record RC.sub.i can comprise a segment-id sid.sub.m (m=1, 2, . . . ). The segment-id sid.sub.m is usually different from the section s.sub.i, since segment-ids sid.sub.m correspond to predetermined road segments sg.sub.1, sg.sub.2, . . . sg.sub.m, . . . of the road 2, as e.g. defined in a map matcher 7′ of the OBU 4 or an external map matcher. When creating an itinerary record RC.sub.i at the end of a section s.sub.i, the OBU 4 can thus retrieve a segment-id sid.sub.m from the internal map matcher 7′ (or an external map matcher) corresponding to any one (or a plurality) of the positions p.sub.n of the set of current positions {p.sub.n}.sub.i, for example, the first position p.sub.f,i or the last position p.sub.l,i of a section s.sub.i, which falls into the road segment sg.sub.m.

[0069] After the time-interval T.sub.i has finished, the OBU 4 gathers a next set of current positions {p.sub.n}.sub.i+1 over a next time interval T.sub.i+1, wherein the last point of time t.sub.f,i of the previous interval may coincide with the first point of time t.sub.f,i+1 of the new interval, and thus the last position p.sub.l,i of the previous set of current positions {p.sub.n}.sub.i may coincide with the first position p.sub.f,i+1 of the new set of current positions {p.sub.n}.sub.i+1. Thus, time intervals T.sub.i, T.sub.i+1, . . . , succeed each other to define sections s.sub.i, s.sub.i+1, . . . , with sets of current positions {p.sub.n}.sub.i, {p.sub.n}.sub.i+1, . . . . The time intervals T.sub.i, T.sub.i+1, . . . , have the same timely length and are thus periodic, although this is not compulsory.

[0070] To implement secure monitoring in the road toll system 1, a trusted element 18 is installed in the proxy server 10, i.e. coupled to the transceiver 12 of the proxy server 10. The trusted element 18 is tamper-proof and comprises a processor 19, an encryption unit 20, and an (optional) id-generator 21; a detailed explanation about the functions of said elements will be given below. To temporarily or permanently store incoming or outgoing data for monitoring purposes, a memory 22 is coupled to the processor 18.

[0071] For purposes mentioned above, the proxy server 10 is connected to the central station 6 via the network 11, and the central station 6 is equipped with a processor 23 and a memory 24 for storing data as forwarded by the proxy server 10.

[0072] It is now referred to FIG. 3 for the method of secure monitoring in the road toll system 1, where a gathering process G.sub.i is executed within the time interval T.sub.i to gather current positions p.sub.n. At the end of the gathering process G.sub.i, i.e. at the last point of time t.sub.l,i, internal processes in the OBU 4 take place over a time interval TC.sub.int to create the itinerary record RC.sub.i. This takes a certain amount of time since especially the calculation of the distance d.sub.i is to be calculated in order to create the itinerary record RC.sub.i.

[0073] The calculation of the distance d.sub.i by means of the gathered set of current positions {p.sub.n}.sub.i can be done in any manner known to the skilled person, e.g. by calculating the distance between adjacent positions p.sub.n or by spline techniques. Alternatively, the distance d.sub.i could also be obtained by map matching by means of the Map Matcher 7′ of the OBU 4, using the first and last position p.sub.f,i, p.sub.l,i or the segment-id sid, or by means of an external map matcher, e.g. in the proxy server 10. When external map matchers are used, however, the “internal” calculation interval TC.sub.int increases significantly.

[0074] After the itinerary record RC.sub.i has been created, i.e. after the internal calculation interval TC.sub.int, the itinerary record RC.sub.i is sent to the proxy server 10 in step 25, where it is received with a delay according to the latency of the mobile network 5.

[0075] In step 26, the itinerary record RC.sub.i is signed in the trusted element 18 of the proxy server 10 by means of the encryption unit 20, e.g., according to a public/private-key scheme, to obtain a signed itinerary record sgn(RC.sub.i).

[0076] Step 26 of signing the itinerary record RC.sub.i may further comprise the attachment of an identification id to the record by means of the id-generator 21 to obtain a signed itinerary record sgn(RC.sub.i,id). The identification id may be signed too, such that it cannot be forged by the OBU 4 or a third party. The id-generator 21 may act as a counter, such that all identifications id are sequential and unique.

[0077] In step 27, the signed itinerary record sgn(RC.sub.i,id) is sent back to the OBU 4 where it is stored in the memory 17 of the OBU 4. Since there is now a signed itinerary record sgn(RC.sub.i,id) present in the OBU 4, it is not mandatory to forward the signed itinerary record sgn(RC.sub.i,id) to the central station 6, since the signed itinerary records sgn(RC.sub.i,id) could be read out from the OBU 4 in a “back office” manner for calculating the toll after a trip by the vehicle 3 in the road toll system 1. However, the proxy server 10 may forward the signed itinerary record sgn(RC.sub.i,id) in step 28 to the central station 6 for evaluation, calculation of charges, etc., where the signed itinerary record sgn(RC.sub.i,id) is processed by the processor 23 and stored in the memory 24 of the central station 6. Alternatively or additionally, the signed itinerary record sgn(RC.sub.i,id) could also be stored in the memory 22 of the proxy server 10.

[0078] Optionally, the unsigned itinerary records RC.sub.i could also be forwarded to the central station 6 or stored in the memory 22 for crosschecking with the signed itinerary records sgn(RC.sub.i,id).

[0079] The signed itinerary record sgn(RC.sub.i,id) is received in the OBU 4 after an interval TC.sub.lat comprising network latencies and the processing time in the proxy server 10, i.e. in total at a time TC.sub.int+TC.sub.lat after the last point of time t.sub.l,i.

[0080] Thus, it can be seen that it takes a significant amount of time to gather current positions p.sub.n, create the itinerary record RC.sub.i and receive the signed itinerary record RC.sub.i, namely the time

T.sub.i+TC.sub.int+TC.sub.lat.

[0081] To check if the OBUs 4 in the road toll system 1 work properly and declare their toll by means of signed itinerary records sgn(RC.sub.i,id), an enforcement system is in place which uses enforcement terminals 29 to check if the OBUs 4 declare their toll properly. The enforcement terminals 29 can be used on vehicles patrolling on the road 3, for example, travelling in the same direction as the vehicles 3 carrying OBUs 4, or the enforcement terminals 29 can be roadside beacons interacting with the OBUs 4.

[0082] To this end, the OBU 4 is equipped with a further transceiver 30 to establish a radio link 31 with an enforcement terminal 29 passing by. The transceiver 30, and therefore the radio link 31, has a radio range of at most a few metres, a few tens of metres or a few hundred metres, as is implemented for example by the DSRC (dedicated short range communication), CEN-DSRC, UNI-DSRC, IEEE 802.11p or WAVE (wireless access for vehicular environments) or ITS-G5 standards inclusive of WLAN and Wifi®, Bluetooth®, or active or passive RFID (radio frequency identification) technologies.

[0083] Alternatively, the enforcement terminal 29 can request the signed itinerary record sgn(RC.sub.i,id) from the OBU 4 via the mobile network 5 or via a public or private data channel, e.g. a virtual private network (VPN). In this embodiment, no DSRC communication means is necessary within the OBU 4, such that even a mobile phone can be used as an OBU 4 by means of suitable software implementations. To determine a match between OBU 4 and vehicle 3, the enforcement terminal 29 can in any case read the license plate number of the vehicle 3, e.g. by OCR-reading, and match the license plate number to a unique OBU-identification by means of a database.

[0084] To check the OBU 4, the enforcement terminal 29 conducts an enforcement process EP1, wherein in step 32 a request req is sent to the OBU 4 to obtain the most recent signed itinerary record(s) sgn(RC.sub.i,id). After receipt of the signed itinerary record(s) sgn(RC.sub.i,id) in step 33, the enforcement terminal 29 checks for plausibility of the received signed itinerary record(s) sgn(RC.sub.i,id). To this end, the enforcement terminal 29 can use a variety of verification schemes, each of which is optional: Firstly, the enforcement terminal 29 can check whether the signature is in fact valid. Secondly, the enforcement terminal 29 can check if the last position as stated in the signed itinerary record sgn(RC.sub.i,id) lies in the vicinity of the current position of the enforcement terminal. Additionally or alternatively, it is checked whether the last point of time lies in a vicinity of a momentary time.

[0085] A further verification scheme tests whether the identifications id of the at least two last received signed itinerary records sgn(RC.sub.i−1,id), sgn(RC.sub.i,id) are successive. This ensures that no signed itinerary records were discarded. Yet another verification scheme requests the signed itinerary record sgn(RC.sub.i,id) stored in the memory 22 of the proxy server 10 and/or stored in the memory 24 of the central station 6 and compares it with the signed itinerary record sgn(RC.sub.i,id) received from the OBU 4, as described later on for the exemplary enforcement process EP4.

[0086] As can be seen from FIG. 3, it takes a considerable amount of time for the signed itinerary record sgn(RC.sub.i,id) to be available in the OBU 4 for enforcement. Thus, a “partial” itinerary record RP comprising only the first position p.sub.f,i and/or the first point of time t.sub.f,i, may be optionally introduced in a further embodiment of the method which is now explained in detail.

[0087] The method for signing the “complete” itinerary record RC.sub.i described holds for the partial itinerary record RP.sub.i as well, i.e. after creation, the partial itinerary record RP.sub.i is sent in step 34 to the proxy server 10 where it is signed by means of a digital signature (and an optional identification id) in step 35 to obtain a signed partial itinerary record sgn(RP.sub.i,id) which is sent back to the OBU 4 in step 36. Furthermore, all mentioned memories 17, 22, and 24 are also configured to store said partial itinerary records RP.sub.i.

[0088] The partial itinerary record RP.sub.i is “partial” in so far as it does not comprise all current positions {p.sub.n}.sub.i of a section s.sub.i, but only some of the first or only the first current position p.sub.f,i of a section s.sub.i, and hence does not comprise the distance d.sub.i driven over the section s.sub.i. Creation of the partial itinerary record RP.sub.i can thus already be conducted at the beginning of the section s.sub.i, reducing the time after which a record declaring the tolling of section s.sub.i is available in the OBU 4 by (at least) the amount T.sub.i.

[0089] In particular, because no distance d.sub.i has to be calculated, the internal calculation time TP.sub.int in the OBU 4 may even be lower than the internal calculation time TC.sub.int for a complete itinerary record RC.sub.i. Also due to the reduced file size and thereby reduced encryption time of the partial itinerary record RP.sub.i the latency time TP.sub.lat for partial itinerary records RP.sub.i is lower than the latency time TC.sub.lat for complete itinerary records RP.sub.i. The total time saving of receiving a signed partial itinerary record sgn(RP.sub.i,id) with respect to the signed complete itinerary record sgn(RC.sub.i−1,id) as received from the preceding section s.sub.i−1 is thus ΔT=TC.sub.int+TC.sub.lat−TP.sub.int−TP.sub.lat.

[0090] Due to the above-mentioned time savings, the signed partial itinerary record sgn(RP.sub.i,id) may in fact be received even earlier than the signed itinerary record sgn(RC.sub.i−1,id) of the previous section s.sub.i−1. If, in one embodiment of the method, the sequentially of the identifications id is considered when the enforcement terminal 29 checks for sequential identifiers id, two different id-generators 19 (counters) can be used for the partial and complete itinerary records RP.sub.i, RC.sub.i, respectively. Another solution would be to consider an expected relationship when checking for sequentially, e.g. the identifier id of the complete itinerary record sgn(RC.sub.i,id) is expected to be higher by three with respect to the identifier id of the partial itinerary record sgn(RP.sub.i,id) declaring the same section s.sub.i.

[0091] Focus is now shifted towards the responses received at the enforcement terminal 29 upon requesting the OBU 4 to issue its last signed complete and/or partial itinerary record. To this end, further exemplary enforcement processes EP2, EP3, and EP4 are explained in the following.

[0092] For an enforcement process EP2 whose step 37 of sending a request req lies at a time t.sub.ep2 with

t.sub.f,i<t.sub.ea2<t.sub.f,i+TP.sub.int+TP.sub.lat,

the enforcement terminal 29 will receive in step 38 the signed complete itinerary record sgn(RC.sub.i−2,id) from the section s.sub.i−2, i.e. the tolling information from two sections ago, and optionally the last signed itinerary record sgn(RP.sub.i−1,id). The enforcement terminal 29 can therefore conclude that the OBU 4 is either in the gathering process G.sub.i−1 or has already finished the gathering process G.sub.i−1 but not yet received the signed partial itinerary record sgn(RP.sub.i,id) from the proxy server 10.

[0093] For an enforcement process EP3 whose step 39 of sending a request req lies at a time t.sub.ep3 with

t.sub.f,i+TP.sub.int+TP.sub.lat<t.sub.ep3<t.sub.f,i+TC.sub.int+TC.sub.lat,

[0094] in which there is an availability AV1 of the signed partial itinerary record sgn(RP.sub.i,id) of the section s.sub.i, the enforcement terminal 29 may receive in step 40 the signed partial itinerary record sgn(RP.sub.i,id) and optionally the signed complete itinerary record sgn(RC.sub.i−2,id), whereupon the enforcement terminal 29 can conclude that the section s.sub.i has been declared for toll, even though there is not even a signed complete record sgn(RC.sub.i−1,id) about the section s.sub.i−1 present in the OBU 4.

[0095] Enforcement process EP4 shows in step 41 a request req at a time t.sub.ep4 with

t.sub.f,i+TC.sub.int+TC.sub.lat<t.sub.ep4<t.sub.f,i+T.sub.i,

[0096] in which there is an availability AV2 of the signed complete itinerary record sgn(RC.sub.i−1,id) of the section s.sub.i−1, which is received in step 42. This enforcement action EP4 holds similarities to the enforcement action EP2: The enforcement terminal 29 can conclude that the OBU 4 is either in the gathering process G.sub.i or has already concluded the gathering process G.sub.i but not yet received the signed partial itinerary record sgn(RP.sub.i+1,id), but it knows for certain that the section s.sub.i will be declared due to the presence of the partial itinerary record sgn(RP.sub.i,id).

[0097] Furthermore, the enforcement process EP4 may send in step 43 a request req CS to the central station 6 to issue the last received partial and/or complete itinerary record in step 44, so that the enforcement terminal 29 can check the plausibility of the itinerary record(s) as received from the OBU 4 in step 42. This measure can also be taken for the enforcement processes EP1, EP2 and EP3.

[0098] All further schemes to check for plausibility as described above for the case of complete itinerary records sgn(RC.sub.i,id) can also be conducted for partial itinerary records sgn(RP.sub.i,id).

[0099] The present subject matter is not restricted to the specific embodiments described in detail herein, but encompasses all variants, combinations and modifications thereof that fall within the framework of the appended claims.