EP3136351B1

EP3136351B1 - Road toll system, on-board unit and method for operating an on-board unit

Info

Publication number: EP3136351B1
Application number: EP15465532.8A
Authority: EP
Inventors: Doru Aldea-Ungurean; Iosif Mudra; Daniel-Adrian Pascu; Sorin Soare; Silviu Stan; Ciprian Vasile Botiz
Original assignee: Continental Automotive Technologies GmbH
Current assignee: Continental Automotive Technologies GmbH
Priority date: 2015-08-26
Filing date: 2015-08-26
Publication date: 2023-10-11
Anticipated expiration: 2035-08-26
Also published as: EP3136351A1

Description

The current invention refers to a road toll system, an on-board unit and a method for operating an on-board unit, particularly an on-board unit in a road toll system.
In many countries all over the world there are toll roads (also known as turnpikes or tollways), for which a fee (or toll) is assessed for passage. Different systems for collecting the toll are known. For example, toll booths or toll plazas where the user may pay the toll may be positioned at entry or exit points of the toll road. Further, electronic road toll systems are known. In electronic road toll systems a unit (so called on-board unit) which may be a GNSS unit (GNSS = Global Navigation Satellite System) is installed in the vehicle. A GNSS unit is a satellite navigation system, which allows to determine the position of the vehicle. Satellite navigation systems use a version of triangulation to locate a user through calculations involving information from a number of satellites. Known GNSS systems are GPS (Global Positioning System) or Galileo, for example.
Document US2015088618 A1 discloses a precision usage-based transportation infrastructure charging service that includes a dynamic road and infrastructure usage engine that can fairly assess road usage based on any combination of mileage, time of day, vehicle mass, location, road class, defined zones and other relevant parameters. T
GB2448743 A discloses an asset tracking system comprising a plurality of mobile devices to be tracked and a central server that is able to communicate with each of the mobile devices over a communications network. Each mobile device sends position data to the central server over the communications network. The central server further sends position data regarding the said mobile devices to each of the mobile devices over the communications network. The position data may be a difference between a previous position and a current position of each mobile device to reduce the amount of data being transferred. T
WO9704421 A1 shows a system and method for determining the distance travelled by a vehicle to enable a charge to be rendered for roadway usage.
US2004162673 A1 discloses a communications device for conveying geographic location information over capacity constrained wireless systems.
While the vehicle is on a toll road (or in a tolling zone), the on-board unit acquires data concerning the vehicle position. Several approaches are known for processing the acquired vehicle position data and calculating the payable toll. One approach is the so-called "Thick-Client-Approach", also known as "Fat-Client-" or "Smart-Client-Approach". Using the Thick-Client-Approach, the toll is calculated directly in the on-board unit. This information is then transmitted to a central office. An advantage of the Thick-Client-Approach is that the data transmission volume is relatively low and tolling information is immediately available at the central office. However, information about toll roads and non-toll roads as well as road toll rates needs to be stored in the on-board unit, which results in low flexibility. For example, if road toll rates change, such information needs to be transmitted to all on-board units of the system. Further, on-board units in a Thick-Client-Approach are rather complex and, therefore, expensive.
Therefore, some countries have implemented the so-called "Thin-Client-Approach". Using this approach, the on-board unit determines the vehicle position, concentrates the data and transmits this position information to the central office. The payable toll is calculated in the central office. Using the Thin-Client-Approach, the system is more flexible, as changes of road toll rates and toll roads can easily be implemented in the central office. However, the data transmission volume is rather high.
The problem to be solved by the current invention is, therefore, to reduce the data transmission volume, especially in systems that use the Thin-Client-Approach.
This problem is solved by an on-board unit according to claim 1, a method according to claim 10 and a road toll system according to claim 11. Configurations and further developments of the invention are subject of the dependent claims.
A vehicle on-board unit for a toll road system comprises a processor, configured to determine the position of the on-board unit in regular intervals and to provide data representing the determined positions, the data including at least one of a latitude, a longitude and a timestamp representing the time at which the correspondent position has been determined. The on-board unit further comprises a communication module, configured to receive the data representing the determined positions, and to generate at least one message, each message including the data of at least two successive positions, whereby the message includes a data header and payload, the payload including the position data, wherein the communication module is also configured to generate the at least one message to include a first timestamp for a first position in each message and to omit timestamps for at least one successive position of the same message.
By including the data of more than one position within one message, the total amount of data may be reduced. For example, one header will then be sent for several positions, not for each single position.
The communication module is configured to generate the at least one message to include a first timestamp for a first position in each message and to omit timestamps for at least one successive position of the same message. By omitting timestamps, the size of each message may be reduced. If the message size is kept constant, the data of more positions may be included within one message.
The communication module may be configured to generate each message to include a first latitude and a first longitude specifying a first position and at least one delta-latitude and delta-longitude specifying at least one successive position, the delta-latitude representing a deviation from the first latitude and the delta-longitude representing a deviation from the first longitude. The size of a delta-longitude is generally smaller than the size of a complete longitude and the size of a delta-latitude is generally smaller than the size of a complete latitude. Therefore, message size may further be reduced by transmitting delta-positions.
The communication module may be configured to generate each message to include data of at least 16 positions, at least 356 positions or at least 710 positions. The more positions are sent within one message, the less headers need to be sent for a certain amount of positions. Data traffic may therefore be reduced.
The communication module may be configured to open a network socket to establish a connection with a central office. The communication module may further configured to transmit the at least one message to the central office while the network socket is open and to close the network socket after transmission of a predetermined number of messages. In this way, less network sockets needs to be opened at the same time.
The communication module may be configured to transmit the at least one message using the Transmission Control Protocol or the User Datagram Protocol.
The communication module may be configured to include the latitude and longitude that define a position each with a precision of 6 decimals. The communication module, however, may also be configured to include the latitude and longitude that define a position each with a precision of 5 decimals. By reducing the number of decimals, the message size may be reduced, while the precision may still be acceptable for billing purposes.
The satellite system may comprise at least four satellites, wherein each satellite is configured to transmit signals, the signals comprising information about the time of transmission and/or the position of the respective satellite at the time of transmission. The on-board unit may be configured to receive signals of at least four satellites of the satellite system at the same time when the on-board unit is in an operating mode and to determine its own position based on these signals. If signals of at least four satellites are received, the position of the on-board unit may be determined.
The road toll system may further comprise a central office, which is configured to receive the message from the communication module. The central office may then do the necessary calculations for billing.
Examples are now explained with reference to the drawings. In the drawings the same reference characters denote like features.

Figure 1: illustrates in a block diagram an example of a road toll system,
Figure 2: illustrates in a block diagram an example of a data transfer between an on-board unit and a central office using a first communication protocol,
Figure 3: illustrates in a block diagram an example of a data transfer between an on-board unit and a central office using a second communication protocol,
Figure 4: schematically illustrates a data packet that is sent from an on-board unit to a central office,
Figure 5: illustrates an example of contents of the data packet of Figure 4 in more detail,
Figure 6: illustrates an example of contents of a data packet according to the present invention,
Figure 7: illustrates a further example of contents of a data packet according to the present invention,
Figure 8: illustrates in a block diagram an example of a data transfer between an on-board unit and a central office,
Figure 9: illustrates a further example of contents of a data packet according to the present invention,
Figure 10: illustrates in a block diagram a further example of a road toll system, and
Figure 11: illustrates in a flow chart an example of a method for operating an on-board unit according to the present invention.

Figure 1 illustrates a road toll system including a satellite system 1, an on-board unit 2 and a central office 3. The on-board unit 2 may be installed in a vehicle, for example. The satellite system 1 may be a global navigation network system, for example, and may include at least four satellites (not shown). The satellites are configured to continually transmit signals, the signals including the time of transmission and the position of the respective satellite at the time of transmission. When the on-board unit 2 receives the signals of at least four satellites at the same time, it may determine its own position. This is, however, only an example. The position of the on-board unit 2 may be determined in any other suitable way. Data X representing the position of the on-board unit 2 may then be transmitted to the central office 3 for billing. Billing may be based on a distance travelled, the time spent in a tolling zone, the location of the on-board unit 2 within the tolling zone and vehicle characteristics, for example.
The position of the on-board unit 2 may be determined in regular intervals, e.g. every second. This, however, is only an example. The position may be determined more or less often than every second.
For data transmission between the on-board unit 2 and the central office 3, different communication protocols may be used. For example, the Internet protocol suite (also known as TCP/IP, Transmission Control Protocol/Internet Protocol) may be used for data transmission. A data transmission according to TCP/IP is schematically illustrated in Fig. 2. The TCP/IP provides, prepares and forwards data packets 4 over a network. A data packet 4 that is sent from the on-board unit 2 to a central office 3 generally includes a header 41 and a message 42, which includes the position data that is needed for billing. A data packet 4 may have a total size of 1492 bytes, for example. The header 41 may include, among other data, the IP (Internet Protocol) address of the central office 3 and may have a size of 40 bytes. The message 42 may have a size of 1492 bytes - 40 bytes = 1452 bytes, for example. This is, however, only an example. The data packet 4, the header 41 and the message 42 may have a larger or a smaller size than specified above.
When the central office 3 receives a data packet 4, an acknowledgement 43 may be sent to the on-board unit 2 to confirm reception of the data. Such acknowledgement 43 may have a size of 40 bytes, for example. The acknowledgement 43 may include only a header, without any further message.
The use of TCP/IP, however, is only an example. Another example for a communication protocol is the User Datagram Protocol (UDP) .
A data transmission according to UDP is schematically illustrated in Fig. 3. UDP uses a simple connectionless transmission model with a minimum of protocol mechanisms. The central office 3 receives the data packet 5 (including a header 51 and a message 52) from the on-board unit 2, but does not send an acknowledgement in return. The on-board unit 2, therefore, does not know if the central office 3 received a message. The communication protocols described above, however, are only examples. Other communication protocols may be used as well to transmit data from the on-board unit 2 to the central office 3.
Referring to Fig. 4, the message 42 of a data packet 4 is illustrated in more detail. The message 42 may contain information about the serial number OBU SN of the on-board unit 2, which is transmitting the data. Further, the message 42 includes a data header and the payload, the payload including the position data. A cyclic redundancy check CRC may be performed to detect accidental changes of the transmitted data. Therefore, a check value CRC of a fixed size may be included in the data packet, forming a codeword. The check value CRC may have a size of 2 bytes, for example. When the codeword is received, the receiving device either compares its check value with a freshly calculated check value or performs a CRC on the codeword and compares the resulting check value with an expected residue constant. The data header, payload and check value CRC together have a certain size. This size may be determined and the data packet may further include information LEN about this size.
Referring to Fig. 5, which illustrates an example of contents of the message 42 in greater detail, the serial number OBU SN of the on-board unit may have a size of 4 bytes. The information LEN about the size of the data header, payload and check value CRC may have a size of 2 bytes. Such data may be sent as plain text (non-encrypted text). The data header may include a preamble (1 byte), information about the size of the message (2 bytes), information about the software version that is used by the on-board unit (1 byte), a timestamp (4 bytes), information about the version of the communication protocol (1 byte) and a command ID (1 byte). The data header may, therefore, have a total size of 10 bytes. To reduce the data transmission volume, information about more than one position is transmitted in one data packet. For example, information about 16 positions may be transmitted in one data packet. In this way, only one header is sent for several positions. If each determined position was sent within a separate packet, a header would be needed for every transmitted position. For each position, a timestamp (e.g. 4 bytes) as well as information about latitude (e.g. 4 bytes) and longitude (e.g. 4 bytes) may be transmitted (resulting in a total size of 12 bytes for each position). A position is generally sufficiently defined if both latitude and longitude are known. The latitude specifies the north-south position of a point on the Earth's surface, whereas the longitude specifies the east-west position of a point on the Earth's surface. The payload, therefore, may have a total size of 16 * 12 bytes = 192 bytes (if 16 positions are included in one data packet). This results in a total size of a data packet of 192 bytes (position data) + 4 bytes (OBU SN) + 2 bytes (LEN) + 10 bytes (data header) + 2 bytes (CRC) = 210 bytes, assuming that the check value CRC has a size of 2 bytes.
The total amount of data that may be typically sent from the on-board unit to the central office within one year will now be illustrated by means of an example.
Assuming that a vehicle is driven 8 hours per day on weekdays only (265 days of driving per year), the total driving time of the vehicle is 7.632.000 seconds/year. If the position is determined every second and information about 16 positions is sent in one data packet, the number of data packets sent per year is 7.632.000/16 = 477.000. This number increases to 715.500, if the vehicle is driven 12 hours per day and to 954.000, when driven 16 hours per day. An even higher number of data packets is sent when the vehicle is also driven on weekends.
Assuming a number of data packets of 477.000 per year and a size of the payload of 182 Bytes (including 18 Bytes of overhead), this results in a total amount of 9,93 Mbytes of data traffic per months, considering a further TCP/IP overhead of 80 Bytes (40 Bytes for message header and 40 Bytes for acknowledgement). If 715.500 data packets are sent per year, in the given example the total amount of data traffic is about 14,90 Mbytes per month. These are, however, only examples to illustrate the large quantity of data that is sent between the on-board unit and the central office. The amount of data, for example, may vary with packet size, number of positions sent within one message and the amount of driving hours of the vehicle.
In order to reduce the total amount of sent data, the vehicle position may be determined less often, e.g. every 2, 3, 4,... seconds. This, however, results in a less precise billing. Another possibility to for reducing the total amount of sent data is to reduce the size of each data packet.
According to Fig. 6, the size of a data packet may be reduced, if a timestamp is not sent for every position. In each data packet, a timestamp may be transmitted only for the first position. For successive positions in the same data packet, the timestamp is omitted. At the central office it is known how often a position is determined, e.g. every second. If the timestamp of the first position is known, the timestamps of successive positions may, therefore, be calculated in the central office (timestamp (n + y) = timestamp (n) + (y * x) seconds), with x specifying the time span between determination of two successive positions (e.g. 1s) . The total size of each data packet is thereby reduced by 15 * 4 bytes = 60 bytes to 210 bytes - 60 bytes = 150 bytes.
Alternatively or additionally, the latitude and longitude may only be included for the first position in each data packet. For following positions in the same data packet, a "delta-latitude" and "delta-longitude" may be transmitted, meaning that not a complete position will be sent to the central office, but information about a deviation from the first position in the same data packet. A data packet including delta-positions for following positions is schematically illustrated in Fig. 7. Assuming that a complete position has a size of 8 bytes (4 bytes for latitude and 4 bytes for longitude), a delta-position may have a size of only 4 bytes (2 bytes latitude and 2 bytes longitude) . If timestamps are omitted for successive positions and successive positions are transmitted as delta-positions, the packet size of 150 bytes (packet size with omitted timestamps) is further reduced by 15 * 4 bytes = 60 bytes to 150 bytes - 60 bytes = 90 bytes.
If the size for following positions is reduced by omitting the timestamp (or transmitting a delta-timestamp, respectively) and/or delta-positions are transmitted for following positions, more positions may be transmitted in one data packet (e.g. 30 or 303 positions instead of 16 positions), without exceeding the maximum size of the data packet. This further reduces the data transmission volume, as less headers need to be sent for the same number of positions.
When using the Transmission Control Protocol (TCP), for example, a connection needs to be established between the on-board unit 2 and the central office 3. This connection may be used for bidirectional data transmission. In order to establish a connection between the on-board unit 2 and the central office 3, both the on-board unit 2 and the central office 3 need to open a so-called network socket. A network socket is an endpoint of an inter-process communication across a network. Opening a socket generally takes about 280 - 300 bytes. Data packets may be transmitted while the sockets are open. Further, acknowledgements may be sent from the central office 3 to the on-board unit 2 while the sockets are open. This is schematically illustrated in Fig. 8.
As the central office 3 generally needs to communicate with more than one on-board unit 2, the central office 3 needs to establish several connections and, therefore, needs to manage several sockets simultaneously. Instead of keeping every socket open continuously while an on-board unit 2 is active (e.g. while the vehicle is driven), some or all sockets may be closed from time to time. For example, a socket may be closed after transmission of a certain number of data packets and an equivalent number of acknowledgements. In one embodiment, the sockets are closed after transmission of five data packets and five respective acknowledgements. Assuming that one data packet has a total size of 1490 bytes, 5 * 1490 bytes = 7450 bytes are sent while the sockets are open. If the header size is 40 bytes, data header size is 16 bytes (including the serial number SN and information LN about the size of the message) and CRC size is 2 bytes, this leaves a size of 5 * 1434 bytes = 7170 bytes for the payload. Assuming that an acknowledgement has a total size of 40 bytes, further 5 * 40 bytes = 200 bytes may be sent before the sockets are closed. If some or all sockets are closed after a certain number of data packets, less sockets need to be managed simultaneously by the central office 3.
Referring to Fig. 9, the size for each delta-latitude and delta-longitude may be further reduced, e.g. to 1 byte. If, for example, the delta-latitude and the delta-longitude each are transmitted with 6 decimals, the size of one delta-position may be 4 Bytes. The precision in such a case is very high (e.g. precision of 0,11132m). If the delta-latitude and delta-longitude are transmitted with only 5 decimals, for example, the size of one delta-position may be reduced to 2 Bytes. The precision (e.g. 1,113 m) may still be sufficient for billing.
Referring to Fig. 10, an exemplary road toll system is illustrated in greater detail. The on-board unit 2 may include a processor 21. The processor 21 may receive signals transmitted from the satellites of the satellite system 1. The processor 21 may further process these signals, determine the position of the on-board unit 2 and may provide data relating to the position of the on-board unit 2. The position data may either be stored in the on-board unit 2 for later transmission or may be transmitted without prior storing. The on-board unit 2 may include a communication module 22. The communication module 22 may transmit data to the central office 3. The data may be transmitted to the central office 3 via a wireless data channel, for example. In this case, it is not required that the vehicle in which the on-board unit 2 is installed return to a billing station to read out the data. The communication module 22 may transmit data to the central office 3 whenever a data connection is available. The data may be transmitted in regular intervals. For example, the data may be transmitted at the end of each day. This is, however, only an example. Data may also be transmitted more or less regularly.
A method for operating an on-board unit 2 is illustrated in Fig. 11. In a first step, the position of the on-board unit is determined (step 601). More precisely, the position may be determined in regular intervals. Data representing the determined positions may then be provided (step 602) . Such data may include at least one of a latitude, a longitude and a timestamp, the timestamp representing the time at which the correspondent position was determined. A message is then generated, including the data of at least two successive positions (step 603) .

Claims

Vehicle on-board unit (2) for a road toll system, the vehicle on-board unit (2) comprising
a processor (21), configured to determine the position of the on-board unit (2) in regular intervals and to provide data representing the determined positions, the data including at least one of a latitude, a longitude and a timestamp representing the time at which the correspondent position has been determined; and

a communication module (22), configured to receive the data representing the determined positions, and generate at least one message (42), each message (42) including the data of at least two successive positions, whereby the message (42) includes a data header and payload, the payload including the position data, wherein the communication module (22) is further configured to generate the at least one message (42) to include a first timestamp for a first position in each message (42) and to omit timestamps for at least one successive position of the same message (42).
On-board unit (2) according to claim 1, wherein the communication module (22) is configured to generate each message (42) to include a first latitude and a first longitude specifying a first position and at least one delta-latitude and delta-longitude specifying at least one successive position, the delta-latitude representing a deviation from the first latitude and the delta-longitude representing a deviation from the first longitude.
On-board unit (2) according to one of claims 1 to 2, wherein the communication module (22) is configured to generate each message (42) to include data of at least 16 positions, at least 356 positions or at least 710 positions.
On-board unit (2) according to one of the preceding claims, wherein the communication module (22) is configured to open a network socket to establish a connection with a central office (3).
On-board unit (2) according to claim 4, wherein the communication module (22) is further configured to transmit the at least one message to the central office (3) while the network socket is open.
On-board unit (2) according to claim 5, wherein the communication module (22) is configured to close the network socket after transmission of a predetermined number of messages (42).
On-board unit (2) according to one of claims 4 to 6, wherein the communication module (22) is configured to transmit the at least one message using the Transmission Control Protocol or the User Datagram Protocol.
On-board unit (2) according to one of the preceding claims, wherein the communication module (22) is configured to include the latitude and longitude that define a position each with a precision of 6 decimals.
On-board unit (2) according to one of claims 1 to 7, wherein the communication module (22) is configured to include the latitude and longitude that define a position each with a precision of 5 decimals.
Method for operating a vehicle on-board unit (2) for a road toll system, the vehicle on-board unit (2) according to claim 1 and the method comprises:
determining the position of the on-board unit (2) in regular intervals;

providing data representing the determined positions, the data including at least one of a latitude, a longitude and a timestamp representing the time at which the correspondent position was determined;

generating a message (42), the message (42) including the data of at least two successive positions, whereby the message (42) includes a data header and payload, the payload including the position data;
the method further comprising generating the at least one message (42) to include a first timestamp for a first position in each message (42) and omitting timestamps for at least one successive position of the same message (42).
Road toll system comprising:
a satellite system (1); and

a vehicle on-board unit (2) according to one of claims 1 - 9.
Road toll system according to claim 11, wherein the satellite system (1) comprises at least four satellites, wherein each satellite is configured to transmit signals, the signals comprising information about the time of transmission and/or the position of the respective satellite at the time of transmission.
Road toll system according to claim 12, wherein the on-board unit (2) is configured to receive signals of at least four satellites of the satellite system (1) at the same time when the on-board unit (2) is in an operating mode and to determine its own position based on these signals.
Road toll system according to one of claims 11 to 13, further comprising a central office (3), which is configured to receive the message from the communication module (22).