EP3136351A1 - Road toll system, on-board unit and method for operating an on-board unit - Google Patents
Road toll system, on-board unit and method for operating an on-board unit Download PDFInfo
- Publication number
- EP3136351A1 EP3136351A1 EP15465532.8A EP15465532A EP3136351A1 EP 3136351 A1 EP3136351 A1 EP 3136351A1 EP 15465532 A EP15465532 A EP 15465532A EP 3136351 A1 EP3136351 A1 EP 3136351A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- board unit
- message
- data
- communication module
- positions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims description 10
- 238000004891 communication Methods 0.000 claims abstract description 37
- 230000005540 biological transmission Effects 0.000 claims description 26
- 238000013459 approach Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 5
- 238000012546 transfer Methods 0.000 description 3
- 230000002457 bidirectional effect Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
- G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
- G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
Definitions
- 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.
- toll roads also known as turnpikes or tollways
- a fee or toll
- Different systems for collecting the toll are known.
- toll booths or toll plazas where the user may pay the toll may be positioned at entry or exit points of the toll road.
- electronic road toll systems are known.
- GNSS Global Navigation Satellite System
- 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.
- GNSS systems are GPS (Global Positioning System) or Galileo, for example.
- 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”.
- 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.
- 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.
- the system is more flexible, as changes of road toll rates and toll roads can easily be implemented in the central office.
- 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.
- An on-board unit 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.
- 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 may be 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 timestamp for a first position and a delta-timestamp for at least one successive position, the delta-timestamp representing a deviation from the first timestamp.
- the size of a delta-timestamp is generally smaller than the size of a complete timestamp. Therefore, message size may be further reduced by omitting timestamp. Further, the data of more positions may be sent within one message. This means that less headers need to be sent for a certain amount of positions.
- 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 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.
- a method for operating an on-board unit comprises determining the position of the on-board unit 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, and generating a message, including the data of at least two successive positions.
- a road toll system comprises a satellite system and an on-board unit.
- the on-board unit 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, and a communication module, configured to receive the data representing the determined positions, and to generate a message, including the data of at least two successive positions.
- 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.
- 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.
- the on-board unit 2 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.
- 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 data packet 4, the header 41 and the message 42 may have a larger or a smaller size than specified above.
- 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.
- UDP User Datagram Protocol
- Fig. 3 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.
- 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 may include 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.
- 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.
- 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.
- information about more than one position may be 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
- the longitude specifies the east-west position of a point on the Earth's surface.
- 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.
- the size of a data packet may be reduced, if a timestamp is not sent for every position.
- a timestamp may be transmitted only for the first position.
- the timestamp may be omitted.
- a complete timestamp may have a size of 4 bytes
- a delta-timestamp may have a size of only 2 bytes, for example.
- the latitude and longitude may only be included for the first position in each 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).
- 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.
- 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.
- TCP Transmission Control Protocol
- 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 .
- header size 40 bytes
- 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.
- 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 .
- 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 may then be generated, including the data of at least two successive positions (step 603).
Abstract
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.
- 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 12 and a road toll system according to claim 13. Configurations and further developments of the invention are subject of the dependent claims. - An on-board unit 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.
- 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 may be 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 timestamp for a first position and a delta-timestamp for at least one successive position, the delta-timestamp representing a deviation from the first timestamp. The size of a delta-timestamp is generally smaller than the size of a complete timestamp. Therefore, message size may be further reduced by omitting timestamp. Further, the data of more positions may be sent within one message. This means that less headers need to be sent for a certain amount of positions.
- 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.
- A method for operating an on-board unit comprises determining the position of the on-board unit 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, and generating a message, including the data of at least two successive positions.
- A road toll system comprises a satellite system and an on-board unit. The on-board unit 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, and a communication module, configured to receive the data representing the determined positions, and to generate a message, including the data of at least two successive positions.
- 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 asatellite system 1, an on-board unit 2 and acentral office 3. The on-board unit 2 may be installed in a vehicle, for example. Thesatellite 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 thecentral 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 thecentral 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 inFig. 2 . The TCP/IP provides, prepares andforwards data packets 4 over a network. Adata packet 4 that is sent from the on-board unit 2 to acentral office 3 generally includes aheader 41 and amessage 42, which includes the position data that is needed for billing. Adata packet 4 may have a total size of 1492 bytes, for example. Theheader 41 may include, among other data, the IP (Internet Protocol) address of thecentral office 3 and may have a size of 40 bytes. Themessage 42 may have a size of 1492 bytes - 40 bytes = 1452 bytes, for example. This is, however, only an example. Thedata packet 4, theheader 41 and themessage 42 may have a larger or a smaller size than specified above. - When the
central office 3 receives adata packet 4, anacknowledgement 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. Theacknowledgement 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. Thecentral office 3 receives the data packet 5 (including aheader 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 thecentral 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 thecentral office 3. - Referring to
Fig. 4 , themessage 42 of adata packet 4 is illustrated in more detail. Themessage 42 may contain information about the serial number OBU SN of the on-board unit 2, which is transmitting the data. Further, themessage 42 may include 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 themessage 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 may be 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 may be 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. Instead of omitting the timestamps for successive positions, it is also possible to send a timestamp for the first position and a "delta-timestamp" for each following position in the same data packet, which only specifies a time difference compared to the first timestamp. Whereas a complete timestamp may have a size of 4 bytes, a delta-timestamp may have a size of only 2 bytes, for example. - 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 thecentral office 3. This connection may be used for bidirectional data transmission. In order to establish a connection between the on-board unit 2 and thecentral office 3, both the on-board unit 2 and thecentral 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 thecentral office 3 to the on-board unit 2 while the sockets are open. This is schematically illustrated inFig. 8 . - As the
central office 3 generally needs to communicate with more than one on-board unit 2, thecentral 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 thecentral 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 aprocessor 21. Theprocessor 21 may receive signals transmitted from the satellites of thesatellite system 1. Theprocessor 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 acommunication module 22. Thecommunication module 22 may transmit data to thecentral office 3. The data may be transmitted to thecentral 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. Thecommunication module 22 may transmit data to thecentral 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 inFig. 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 may then be generated, including the data of at least two successive positions (step 603).
Claims (16)
- 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. - On-board unit (2) according to claim 1, wherein the communication module (22) is 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 timestamp for a first position and a delta-timestamp for at least one successive position, the delta-timestamp representing a deviation from the first timestamp.
- On-board unit (2) according to one of claims 1 to 3, 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 4, 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 6, 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 7, 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 6 to 8, 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 9, 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 an on-board unit (2), 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, including the data of at least two successive positions.
- Road toll system comprising:a satellite system (1); andan on-board unit (2), the on-board unit (2) comprisinga 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, anda communication module (22), configured to receive the data representing the determined positions, and to generate a message, including the data of at least two successive positions.
- Road toll system according to claim 13, 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 14, 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 13 to 15, further comprising a central office (3), which is configured to receive the message from the communication module (22).
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP15465532.8A EP3136351B1 (en) | 2015-08-26 | 2015-08-26 | Road toll system, on-board unit and method for operating an on-board unit |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP15465532.8A EP3136351B1 (en) | 2015-08-26 | 2015-08-26 | Road toll system, on-board unit and method for operating an on-board unit |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3136351A1 true EP3136351A1 (en) | 2017-03-01 |
EP3136351B1 EP3136351B1 (en) | 2023-10-11 |
Family
ID=54291234
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP15465532.8A Active EP3136351B1 (en) | 2015-08-26 | 2015-08-26 | Road toll system, on-board unit and method for operating an on-board unit |
Country Status (1)
Country | Link |
---|---|
EP (1) | EP3136351B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3944203A1 (en) | 2020-07-23 | 2022-01-26 | Toll Collect GmbH | Method and system for recording position data in a toll system |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1997004421A1 (en) * | 1995-07-24 | 1997-02-06 | D & E Consulting Pty. Ltd. | System and method for determining the distance travelled by a vehicle |
US5717389A (en) * | 1994-01-28 | 1998-02-10 | Detemobil Deutsche Telekom Mobilnet Gmbh | Method of determining toll charges for vehicles using a traffic route |
GB2448743A (en) * | 2007-04-26 | 2008-10-29 | Eads Defence And Security Systems Ltd | Bi-directional communication in an asset tracking system |
GB2510174A (en) * | 2013-01-28 | 2014-07-30 | Canon Kk | Encoding message headers using an in-memory indexing table |
US20150088618A1 (en) * | 2013-08-26 | 2015-03-26 | Ims Solutions, Inc. | Road tolling |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6718237B1 (en) * | 2002-03-28 | 2004-04-06 | Numerex Investment Corp. | Method for reducing capacity demands for conveying geographic location information over capacity constrained wireless systems |
-
2015
- 2015-08-26 EP EP15465532.8A patent/EP3136351B1/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5717389A (en) * | 1994-01-28 | 1998-02-10 | Detemobil Deutsche Telekom Mobilnet Gmbh | Method of determining toll charges for vehicles using a traffic route |
WO1997004421A1 (en) * | 1995-07-24 | 1997-02-06 | D & E Consulting Pty. Ltd. | System and method for determining the distance travelled by a vehicle |
GB2448743A (en) * | 2007-04-26 | 2008-10-29 | Eads Defence And Security Systems Ltd | Bi-directional communication in an asset tracking system |
GB2510174A (en) * | 2013-01-28 | 2014-07-30 | Canon Kk | Encoding message headers using an in-memory indexing table |
US20150088618A1 (en) * | 2013-08-26 | 2015-03-26 | Ims Solutions, Inc. | Road tolling |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3944203A1 (en) | 2020-07-23 | 2022-01-26 | Toll Collect GmbH | Method and system for recording position data in a toll system |
Also Published As
Publication number | Publication date |
---|---|
EP3136351B1 (en) | 2023-10-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2013200442B2 (en) | Control method for a road toll system | |
US8489327B2 (en) | Navigation device and method for providing alternative network connections | |
US7010289B2 (en) | Method and system for vehicle data upload | |
KR100986372B1 (en) | Terminal for Collecting Traffic Information and Method for Generating Traffic Information | |
US11223934B2 (en) | Road-vehicle communication system, roadside communication apparatus, in-vehicle communication apparatus, and road-vehicle communication method | |
US20060166656A1 (en) | Cell or mobile phone, and wireless PDA traffic advisory method | |
Al-Taee et al. | Remote monitoring of vehicle diagnostics and location using a smart box with global positioning system and general packet radio service | |
US20070016539A1 (en) | Smart meter parking system | |
US20060184322A1 (en) | Traffic Information Service Based on Traffic Information Transmitted to a Navigation System | |
CN105974453A (en) | Difference location method based on intelligent vehicular access cooperation system and intelligent vehicular access cooperation system | |
EP1708143A2 (en) | System for processing position and/or toll related data for vehicles | |
CN106251423B (en) | Vehicle accident recording apparatus and method of generating accident information thereof | |
EP2487506A1 (en) | Positioning device, method and computer program product for signalling that a positioning device is not functioning as intended | |
GB2425858A (en) | Map correction | |
EP3136351B1 (en) | Road toll system, on-board unit and method for operating an on-board unit | |
EP3082110A1 (en) | Road toll system, on-board unit and method for operating an on-board unit | |
CN109541661B (en) | Positioning method and device | |
US9644972B2 (en) | Method for tracking a path taken by a vehicle | |
US20130261963A1 (en) | Road side data exchange net and method thereof | |
EP3142078A1 (en) | Central unit, road toll system and methods for operating a road toll system and a central unit | |
CN113630739A (en) | PC5 short-range communication road side equipment for providing high-precision positioning service | |
RU113396U1 (en) | GLONASS / GPS SATELLITE TELEMATIC COMPLEX USING Inmarsat D + / GPRS COMMUNICATION CHANNELS | |
EP2280287B1 (en) | Integration of positioning and road charging data | |
JP2019522426A (en) | Method of data transmission between an on-board device and a remote processing center configured to acquire data relating to vehicle motion and / or driving parameters | |
EP4130799A1 (en) | Vehicle movement tracking |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20170901 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: CONTINENTAL AUTOMOTIVE GMBH |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20200828 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
GRAJ | Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted |
Free format text: ORIGINAL CODE: EPIDOSDIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
INTG | Intention to grant announced |
Effective date: 20230116 |
|
INTC | Intention to grant announced (deleted) | ||
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
INTG | Intention to grant announced |
Effective date: 20230411 |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230522 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602015086036 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: FP |
|
REG | Reference to a national code |
Ref country code: SK Ref legal event code: T3 Ref document number: E 42711 Country of ref document: SK |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG9D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R081 Ref document number: 602015086036 Country of ref document: DE Owner name: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH, DE Free format text: FORMER OWNER: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH, 30165 HANNOVER, DE |
|
P02 | Opt-out of the competence of the unified patent court (upc) changed |
Effective date: 20240207 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1621001 Country of ref document: AT Kind code of ref document: T Effective date: 20231011 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20240112 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20240211 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20231011 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20231011 |
|
RAP4 | Party data changed (patent owner data changed or rights of a patent transferred) |
Owner name: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH |