Method of and system for receiving and filtering data which are transmitted in multiple cycles

Abstract

 A method of receiving and processing data (10) which are transmitted in multiple cycles (C1-C4) comprises the steps of: receiving at least a first portion of data (21) in one of the cycles (C1) and at least a second portion of data (22, 23) in a succeeding one of the cycles (C2, C3), determining a respective time of receipt (73) of the first and second portion of data (21, 22, 23), and checking a checksum (13) for each of the first and second portions of data. In the event that the checksums (13) for the first and second portions of data (21, 22, 23) do not correspond with each other, the second portion of data (22) is processed. In the event that the checksums (13) for the first and second portions of data correspond with each other, it is checked for the second portion of data (22, 23) whether a preset time (ta, t2) since receipt of the first portion of data (21) has elapsed, and in the event that the preset time has elapsed, the second portion of data (23) is processed, otherwise the second portion of data (22) is discarded.

Description

Background of the Invention

Field of the Invention

[0001] The present invention is directed to a method of and system for receiving and processing data which are transmitted in multiple cycles, wherein at least a first portion of data is received in one of the cycles and at least a second portion of data is received in a succeeding one of the cycles. The system comprises a receiver for receiving the data in a respective cycle and a data processing device coupled with the receiver through a data transmission path for receiving data from the receiver and for further processing thereof. The invention is particularly applicable for receiving and processing coded traffic information according to a standard data format, especially according to the RTTD (real time traffic data) or the TMC (traffic message channel) technology.

Description of the Related Art

[0002] Generally, the traffic message channel (TMC) technology is a technology for delivering traffic and travel information to drivers, such as a driver of a vehicle. Typically, the individual TMC messages are transmitted repeatedly in multiple cycles transmitting the data in temporal loops over the multiplWe cycles. For example, one cycle includes multiple messages such as multiple data packets or data portions, wherein the time period for one cycle may be, for example, approximately 1.5 to 2.5 minutes. In this way, within one cycle traffic information for various streets and/or locations is transmitted in coded manner, wherein the data for each of the streets or locations are repeatedly transmitted over the multiple cycles. Therefore, the driver of a vehicle is continually provided with traffic information from an external traffic information provider, wherein the traffic messages are received, for example, from a satellite used by the traffic information provider. However, a typical traffic information provider generally updates the traffic messages for the individual locations or streets at time intervals which are typically longer than each of the individual cycles according to which the messages are sent to the driver, so that changed traffic messages may occur at greater time distances, for example every 5 minutes.

[0003] Typically, a data format of a traffic message such as a TMC message includes multiple data blocks or fractions including information such as control parameters, identifiers, control flags and the message content itself. For instance, the data format of a TMC data packet may include a so called "all-flag" which indicates or designates the last data packet of one cycle. Generally, a current solution of processing TMC messages is to process all data packets unfiltered and to check for the individual cycle using the "all-flag". Typically, when the TMC data packets are received, a receiver which receives the data packets analyses the individual packets, wherein the receiver may particularly analyse a special identifier parameter sent with the individual packet identifying to which region or location the individual data packet belongs.

[0004] In one receiving and processing mode, the received data packets may be transmitted from the receiver to a subsequently coupled data processing device, such as a navigation system of the vehicle, permanently so that the individual data packets are transmitted on the transmission path between the receiver and the navigation system permanently upon their respective receipt. This provides the disadvantage that the data transmission path is burdened with a rather high data amount. Another solution proposes the storage of a request of the navigation system to send an individual cycle only once, wherein the "all-flag" is used for detecting an end of the cycle. However, such process affords spending a lot of time while waiting for the end of the previous cycle, and may also imply receiving too much data packets in case that the end of the current cycle is not detected. Moreover, this also affords a complex handling of the system status and also provides the disadvantage that lost data packets within one cycle cannot be detected or be received once again. Particularly, the handling of the system status involves employing an internal marker for identifying whether a current data cycle is currently in process, or not. Only when it is identified by the receiver that all data of that cycle are received and that the data cycle is no longer in progress, the received data may be sent to the navigation system.

[0005] On the other hand, the other option of permanently sending the data packets to a navigation system requires a large processing capability in the navigation system for processing the huge data amount and speed in which the data packets are sent from the satellite and receiver to the navigation system. Moreover, the navigation system requires processing means for finding duplicate entries of messages in the navigation system so that such duplicate entries may be updated upon receiving a new message. Accordingly, with transmitting the data packets permanently from the receiver to the navigation system, a huge amount of data must be processed in the navigation system even if the content of the data packets has not changed.

[0006] In EP 1 150 449 A1 there is disclosed a method and apparatus for reducing data communication in an RDS TMC message environment. Particularly, a cycle of messages is processed, wherein each message is consecutively repeated several times as a subsequence of that cycle. First, a message is received and checked for correctness thereof. Next, the correct message is forwarded for further processing, wherein after the checking the most recent message is compared with its direct predecessor and upon correspondence therebetween, the predecessor is forwarded accompanied by a validation signal when detecting that the predecessor was the first correct message of its actual subsequence. In this way, a short-time discarding mechanism at an early stage of the RDS TMC processing is achieved, so that messages may be discarded immediately without even considering the relevance of their information content.

Summary of the Invention

[0007] It is therefore an object of the present invention to provide a method of and system for receiving and processing data transmitted in multiple cycles which are capable of reducing the amount of data transmitted between a receiver device and a data processing device coupled with the receiver device.

[0008] The invention provides a method of receiving and processing data which are transmitted in multiple cycles comprising the steps according to claim 1. Moreover, the invention is directed to a system for receiving and processing data which are transmitted in multiple cycles according to the features of claim 9. Embodiments and advantageous features thereof are indicated in the dependent claims.

[0009] Particularly, the invention provides a method of receiving and processing data which are transmitted in multiple cycles, the method comprising the step of receiving at least a first portion of data in one of the cycles and at least a second portion of data in a succeeding one of the cycles, and further comprising the step of determining a respective time of receipt of the first and second portion of data, and checking a checksum for each of the first and the second portions of data. In the event that the checksums for the first and second portions of data do not correspond with each other, the second portion of data is processed, particularly transmitted from the receiver to the data processing device coupled therewith. In the event that the checksums for the first and second portions of data correspond with each other, the method includes the step of checking for the second portion of data whether a preset time since receipt of the first portion of data has elapsed, and in the event that the preset time has elapsed, the second portion of data is processed, particularly transmitted to the data processing device, otherwise a second portion of data is discarded.

[0010] According to the invention, the method and system for receiving and processing data are each capable of reducing the amount of data transmitted between the receiver and the data processing device. For instance, the receiver and the data processing device may be included in a vehicle, wherein the receiver may be adapted for receiving coded traffic information from an external traffic information provider and the data processing device may be included in a navigation system of the vehicle. In this way, the invention serves to reduce the amount of data transmitted between the receiver and the navigation system, so that the navigation system is not required to provide or reserve large processing capabilities for processing the data received from the receiver. Thus, the invention allows reducing the amount of data which is to be processed in the navigation system.

[0011] To this end, the concept of the present invention involves a filtering mechanism implemented in the receiver, the filtering mechanism detecting already received and processed data portions which have been received and processed in an earlier cycle. This is accomplished in a fast and an efficient way by checking a respective checksum for each of the received portions of data. Typically, a checksum is a well known technique for detecting errors in transmitted data. In the present context, however, the invention uses the means of a checksum for checking for each of the received portions of data whether a respective portion of data has already been received and processed in an earlier cycle. In the event that the checksums for different portions of data of different cycles do not correspond with each other, this is an indication that the different portions of data themselves do not correspond with each other, so that the system may decide that the newly received portion of data has not been received and processed earlier. In this way, the system may initiate further processing of the newly received or changed portion of data.

[0012] On the other hand, in order to ensure proper working of the system, even in the event that the checksums for the different portions of data correspond with each other, the recently received portion of data is processed after a preset time has elapsed to prevent timeout of the system. However, on the other hand when the checksums correspond with each other and the preset time has not elapsed, the recently received portion of data is discarded, particularly not transmitted to the navigation system. In this way, the amount of data transmitted on the transmission path between the receiver and the navigation system may be reduced significantly filtering already received and processed data within a certain time period already at the receiver stage.

[0013] According to an embodiment of the invention, the step of checking for the second portion of data whether a preset time has elapsed includes checking whether a preset time period counting from the time of receipt of the first portion of data has elapsed.

[0014] According to another embodiment of the invention, each of the portions of data comprises a respective data fraction including a checksum associated with the respective one of the portions of data. Further, the step of checking the checksum for each of the portions of data includes checking the checksum of the respective data fraction. In this way, if the data format of the received portions of data provides a respective data fraction including a checksum, this checksum of the transmitted portion of data may be used for checking whether a corresponding portion of data has already been received and processed in an earlier cycle.

[0015] According to another embodiment of the invention, the step of checking the checksum for each of the portions of data involves calculating the respective checksum of the associated portion of data, particularly performing a cyclic redundancy check against the respective portion of data. In this way, the system does not require the transmission of a checksum with the respective data portion, but may calculate the respective checksum for a subsequent check thereof.

[0016] According to a further embodiment, the invention may further include a mechanism for discriminating the individual portions of data whether they represent important or unimportant information. To this end, at least the second portion of data comprises a data fraction including information as to whether the second portion of data represents important data. In the event that the data fraction includes the information that the second portion of data represents important data, the second portion of data is processed. In this way, important data portions may be processed immediately upon their respective receipt.

[0017] Further advantageous features and embodiments of the invention are evident from the dependent claims.

Brief description of the Drawings

[0018] The invention will now be explained in more detail by means of embodiments taken in conjunction with accompanying drawings, in which:

Figure 1

shows a schematic block diagram of a system configuration according to an embodiment of the invention;

Figure 2

shows a schematic illustration of a data format used for receiving and processing information according to an embodiment of the invention;

Figure 3

shows a flow chart of a process for receiving and processing information according to an embodiment of the invention;

Figure 4

shows a flow chart of a process for receiving and processing information according to another embodiment of the invention;

Figure 5

shows a schematic illustration of an exemplary data flow over multiple cycles showing the processing of individual data packets according to an embodiment of the invention;

Figure 6

shows a schematic illustration of another exemplary data flow over multiple cycles according to another embodiment of the invention.

[0019] In Figure 1 tere is shown a schematic block diagram of a system configuration according to an embodiment of the invention. The system 1 according to Figure 1 comprises a receiver 2 for receiving of data via an antenna 6, which data may be, for instance, coded traffic information data provided from an external traffic information provider which may use, for example, a satellite for transmitting the traffic information. For example, the system 1 is implemented in a vehicle, wherein the receiver 2 is capable of receiving data via antenna 6 provided from the satellite. In this context, any other signal transmission technology may be used, such as signal transmission using mobile phone technology like GPRS or UTMS signal transmission. In principal, optical signal transmission may be used as well. The receiver 2 is coupled with a data processing device 5 via a data transmission path 4, which may be, e.g., any kind of communication bus connection such as a standard bus used for connecting electrical components in an automobile. The data processing device 5 may be a subunit of a navigation system 3, particularly, may be a subunit for processing the coded traffic information received from receiver 2. In case that the received data are traffic messages, the data processing device 5 may be implemented as a TMC module or any other module appropriate for receiving and processing traffic messages. In a system 1 according to Figure 1, traffic messages may operate not only to inform the driver, but also to provide dynamic navigation, which means consideration of the current traffic situation during computation of the travel route in the navigation system 3. If the current travel situation was transmitted by traffic messages, the navigation system may provide suggestions, such as how to avoid a traffic jam.

[0020] Although the system 1 of Figure 1 will be described as a system for receiving and processing coded traffic information such as RTTD or TMC messages, it will be understood by those skilled in the art that the system configuration as shown in Figure 1 may basically be applied to any kind of system for receiving and processing data which are transmitted in multiple cycles. For example, the receiver 2 may additionally or alternatively be adapted for receiving data portions via a wired connection, and the devices 3 and 5 may be basically any device for receiving and processing the data received from the receiver 2 which filters the data in accordance with the principles of the present invention. Further, the receiver 2 and data processing devices 3 and 5 may be realized as distributed components, or may be realized as integrated components, wherein the transmission path 4 may be any kind of data connection.

[0021] Figure 2 shows a schematic illustration of a data format used for receiving and processing of information according to an embodiment of the invention. Particularly, Figure 2 shows a data format used for transmitting traffic messages, wherein in Figure 2 only parts of a traffic message are shown which are considered with respect to the invention. A traffic message may be regarded as a data packet. According to the present invention, it is generally referred to a portion of data which may be such data packet, for example. However, any other kind of data portion in any other format may also be applied in the context of the present invention.

[0022] A data packet 10 may include the content of a traffic message itself, generally referred to as data in a data block 12. Further, the data packet 10 may include a data block or data fraction 13 including a checksum associated with the respective data packet 10. Moreover, the data packet 10 may include an additional identifier information generally referred to as "id" in data block 11. In a typical implementation of a traffic message, the identifier information "id" may be a so-called physical stream identifier ("PSI") used for indicating a geographical location or region the respective data packet 10 is associated with. It will be appreciated by the person skilled in the art that also other data formats may be used for implementing the present invention.

[0023] In Figure 3 there is shown a flow chart of a process for receiving and processing of information according to an embodiment of the invention. For a better understanding of the invention, the flow chart of Figure 3 will be explained in the following in conjunction with Figures 5 and 6 each showing a schematic illustration of an exemplary data flow over multiple cycles showing the processing of individual data packets according to a respective embodiment of the invention.

[0024] In Figures 5 and 6, individual data packets 10 are repeatedly transmitted in multiple cycles, wherein each cycle comprises multiple data packets 10 of different content, respectively denoted as data packets A, B, C, I. For example, data packets A, B, C denote so-called speed and flow packets indicating, for example, the speed of traffic and flow parameters, whereas data packet I denotes a so-called incident packet transmitting a parameter for informing about, e.g., a traffic jam or a vehicle driving against the traffic on motorways. Such data packets may also include an identifier included in a data fraction indicating that such type of information represents important data. The other data packets shown in Figure 5 and 6 denoted as "o" represent any kind of data containing additional information which is only optional, such as music or weather information. The individual data packets A, B, C, I are different from each other particularly in their respective data fraction 12 as shown in Figure 2, in other words represent data packets which do not correspond with each other as they contain different traffic message content. For example, data packets A, B, C may concern different locations or streets.

[0025] As further shown in Figures 5 and 6, data packets a, b, c, i indicate individual data packets which are respective repetitions of the data packets A, B, C, I received in earlier cycles. For example, data packet a corresponds with data packet A received in an earlier data cycle, which means that the information content in data fraction 12 (Figure 2) has not changed between data packet A and data packet a.

[0026] For example, referring to Figure 5, data packet A is received for the first time in cycle C1, denoted as data packet 21, like data packets B, C and I. Another data packet a is received in cycle C2, denoted as data packet 22, wherein the lower case letter indicates that the data packets 21 and 22 correspond with each other. In the present context, the information content of data packets 21 and 22 has not changed, i.e. data packet 22 is a repetition of the earlier received data packet 21. Generally, data packets 21 and 22 shall be understood as coinciding in their characteristics, so that it is not necessary for the system to also process data packet 22 when data packet 21 has already been received and processed. The above explanation is also applicable analogously to data packets B, C, I and b, c, i, respectively (capital letters showing new or changed data, whereas lower case letters showing respective repetitions). As further shown in Figure 5, an unchanged data packet a is also received in cycle C3 and C4, denoted as data packets 23 and 24, respectively.

[0027] Now referring to Figure 3, at step 101 the individual data packet is received by the receiver 2 according to Figure 1. The data packets may be, for example, so-called SDTP (serial data transport protocol) packets, wherein the receiver 2 may filter the received data packets according to the PSI parameter and may also determine the status of the respective packet. When receiving the respective data packet, the receiver 2 also determines a respective time of receipt of the individual data packet. In a next step 102, the filter algorithm implemented in receiver 2 checks for a checksum for each of the received data packets, particularly checks whether the corresponding checksum can be found in a management table 7 implemented and updated in receiver 2. Particularly, when the data received are data packets in the format as shown with reference to data packet 10 according to Figure 2, the step 102 of checking the checksum for each of the received data packets includes checking the checksum included in data fraction 13 of the respective data packet. In the management table 7, entries for respective earlier received data packets have been established indicating the checksum (CRC; "Cyclic redundancy check") in column 71 of the management table 7, the type of data (only for information purposes) in column 72, and the time of receipt of the respective data packet ("timestamp") in column 73. The CRC is a known, exemplary type of function used to produce a checksum. A version thereof is the CRC32, which may also be used, as a known implementation of the CRC with improved performance due to including more information. For each of the previously received data packets or messages, the management table 7 contains a respective row.

[0028] In step 102, it is determined whether the checksum of the newly received data packet can be found in the management table 7 which would indicate that a corresponding data packet has been received in an earlier cycle. To this end, it is determined whether the CRC information included in data fraction 13 corresponds with any of the stored CRCs in column 71 of management table 7. For example, the process may implement a comparison between the CRC information in data fraction 13 and any of the stored CRCs in column 71 of the management table 7.

[0029] According to another embodiment of the invention, in case that the data format does not include any data fraction 13 including a checksum, the process according to Figure 3 may calculate, for example at step 101, the respective checksum of the respective data packet received, particularly performing a cyclic redundancy check against the respective data packet. Similar as described above, such calculated CRC information may be compared with any of the CRCs in column 71 of management table 7.

[0030] In the event that the checksum for the recently received data packet does not correspond with any of the checksums according to table 7, the respective CRC information and time of receipt (timestamp) are inserted in table 7, e.g. creating a new row in the table for a new data packet, or updated for a changed data packet. Further, this recently received data packet is further processed. In the embodiment of Figure 1, this data packet is transmitted from receiver 2 to the module 5 of the navigation system. In other words, the receiver 2 transmits in this event a newly received or changed data packet to the navigation system 3.

[0031] This event is particularly indicated in Figure 6 with data packets 21 and 22, wherein the capital letter A of data packet 22 indicates that a changed data packet has been received with respect to the earlier received data packet 21. In cycle C3, however, the data packet 23 corresponds with data packet 22 as shown by the lower case letter "a", as it is also the case for data packet 24 received in cycle C4. For this data packets, a corresponding CRC is found in column 71 of management table 7 in step 102.

[0032] In the event that the checksum of the recently received data packet corresponds with any of the checksums as listed in management table 7, the process implemented in receiver 2 checks for the recently received data packet whether a preset time since receipt of the earlier data packet having the corresponding checksum has elapsed (step 103). According to an embodiment, it is checked whether a preset time period counting from the time of receipt of the earlier data packet has elapsed. This is illustrated in Figure 5 by the exemplary preset time period ta, being approximately 5 minutes just by way of an example. Particularly, in step 103 it is checked whether the preset time period ta has elapsed at the time of receipt t2 of the data packet 23 with respect to the time of receipt t1 of the data packet 21 having the corresponding checksum. In the example of Figure 5, at time t2 the time period ta has elapsed, so that the data packet 23 is processed, i.e. transmitted to navigation system 3, in order to prevent timeout of the system. If it is determined that the time period ta has elapsed (timestamp expired in step 103) the CRC information and timestamp of the previously received data packet 21 is updated with the CRC information and the timestamp of the recently received data packet 23 in step 104. In step 105, the recently received data packet 23 is processed and sent to the navigation system.

[0033] On the other hand, if it is determined in step 103, e.g. as for data packet 22 in Figure 5, that the preset time period ta has not elapsed, i.e. the timestamp of the corresponding data packet 21 has not expired, the recently received data packet 22 is discarded, i.e. not processed and transmitted to the navigation system, thus reducing the amount of data transmitted over transmission path 4. In this way, the data packets are prefiltered for the navigation system in the receiver, wherein only new or changed data packets with respect to previous cycles are transmitted to the navigation system. With detecting corresponding data packets of different cycles by using the checksum, particularly the CRC code, there is provided a fast and efficient way for checking the data packets upon correspondence therebetween. In order to ensure the proper working of a defined timeout handling in the navigation system, the data packets are sent to the navigation system in either case after a preset time period ta, in the present example at least every 5 minutes in order to update the internal timeout management regarding the particular, so called ALERT-C protocol. This provides the further advantage that the navigation system, particularly the module 5, may provide less processing capability with respect to processing the received data from the receiver. In effect, the original traffic message protocol and handling may be used in the navigation system, but the data amount which is transferred over the communication path between receiver and navigation system is less.

[0034] According to an alternative embodiment as shown in Figures 5 and 6, instead of using the preset time period ta, the process implemented in receiver 2 may set respective time triggers, such as time triggers tr1, tr2 shown in Figures 5 and 6, at respective time intervals. In the event that the checksums of at least two data packets correspond with each other, it is determined whether one of the time triggers tr1, tr2 is between the time of receipt of the earlier received data packet and the time of receipt of the recently received data packet. In the event that the time trigger is in-between, the recently received data packet is processed, otherwise the recently received data packet is discarded. For example, referring to Figure 5, when receiving data packet 23 which corresponds with data packet 21 received in an earlier cycle, it is determined that the time trigger tr2 is between the time of receipt t1 (i.e. the timestamp) of the data packet 21 and the time of receipt t2 (timestamp) of the data packet 23, so that it is decided that the data packet 23 is processed and transmitted to the navigation system. On the other hand, this is not the case for data packet 22 with respect to data packet 21 corresponding with each other, so that data packet 22 is discarded.

[0035] In Figure 4 there is shown another flow chart of a process according to another embodiment of the present invention. The process according to Figure 4 is substantially the same as the process according to Figure 3, wherein the process according to Figure 4 is applied to data packets which can only uniquely be identified by using the combination of the PSI-parameter and checksum (CRC-parameter). Accordingly, in the management table 7 according to Figure 4 there is a further column 74 for storing the PSI parameter. In step 102 it is checked for the recently received data packet whether its combination of PSI and CRC parameter is found in management table 7. The subsequent steps 103 to 105 are carried out analogously as explained with reference to Figure 3. The PSI parameter may also include information as to whether the respective data packet represents important data, wherein in the event that the PSI parameter indicates important data, the respective data packet is processed immediately. This may be advantageous for incident messages which may indicate to the driver that, e.g., another vehicle is driving against the traffic on motorways and/or on a wrong carriage way.

[0036] The invention ensures that all information is transmitted to the navigation system as fast as possible after the start up of the system, as in this case the management table is empty and no corresponding checksums can be found for the respective received data packets. As a further advantage, also information is processed as fast as possible in case of previous signal interception of the signal transmission connection, as in this event the respective timestamps of the earlier received data packets have expired, so that in both cases the invention may be applied efficiently for processing received data immediately after receipt. On the other hand, unnecessary data are prefiltered in the receiver, thus reducing the amount of data transfer between receiver and navigation system.

[0037] While the invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the claims. Therefore, it is intended that the invention will not be limited to the particular embodiments disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.

Claims

1. A method of receiving and processing data (10) which are transmitted in multiple cycles (C1-C4), comprising the steps of:

- receiving at least a first portion of data (21) in one of the cycles (C1) and at least a second portion of data (22, 23) in a succeeding one of the cycles (C2, C3),

- determining a respective time of receipt (73) of the first and second portion of data (21, 22, 23), and checking a checksum (13) for each of the first and second portions of data,

- in the event that the checksums (13) for the first and second portions of data (21, 22, 23) do not correspond with each other, processing the second portion of data (22, 23),

- in the event that the checksums (13) for the first and second portions of data correspond with each other, checking for the second portion of data (22, 23) whether a preset time (ta, t2) since receipt of the first portion of data (21) has elapsed, and in the event that the preset time has elapsed, processing the second portion of data (23), otherwise discarding the second portion of data (22).

2. The method according to claim 1, wherein
the step of checking for the second portion of data (22, 23) whether a preset time has elapsed includes checking whether a preset time period (ta) counting from the time of receipt of the first portion of data (21) has elapsed.

3. The method according to claim 1 or 2, further comprising:

- setting time trigger (tr1, tr2) at respective time intervals,

- in the event that the checksums (13) of the first and second portion of data (21-23) correspond with each other, determining whether one of the time trigger (tr2) is between the time of receipt (73) of the first portion of data and the time of receipt (73) of the secod portion of data,

- in the event that the one of the time trigger (tr2) is in-between, processing the second portion of data (23), otherwise discarding the second portion of data (22).

4. The method according to one of claims 1 to 3, wherein
each of the first and second portions of data (21 - 23) comprise a respective data fraction (13) including a checksum associated with the respective one of the first and second portion of data, and wherein the step of checking the checksum for each of the first and second portions of data includes checking the checksum of the respective data fraction.

5. The method according to any one of claims 1 to 4, wherein
the step of checking the checksum for each of the first and second portions of data (21 - 23) involves calculating the respective checksum of the first and second portions of data, particularly performing a cyclic redundancy check against the first and second portions of data.

6. The method according to any one of claims 1 to 5, wherein

- at least the second portion of data (22) comprises a data fraction (11) including information as to whether the second portion of data represents important data,

- in the event that the data fraction (11) includes the information that the second portion of data represents important data, processing the second portion of data (22).

7. The method according to any one of claims 1 to 6, wherein
the first and second portions of data (21 - 23) include coded traffic information to be transmitted to a vehicle, and the method is implemented in a receiver device (2) included in the vehicle.

8. The method according to claim 7, wherein
the first and second portions of data (21 - 23) each include an additional identifier information (psi) indicating a geographical region or location the respective first and second portions of data are associated with, wherein the method includes the additional step of pre-filtering the first and second portions of data according to the identifier information.

9. A system (1) for receiving and processing data which are transmitted in multiple cycles (C1-C4), comprising:

a receiver (2) for receiving data (10) in a respective cycle, and a data processing device (5) coupled with the receiver (2) through a data transmission path (4) for receiving data from the receiver and for further processing thereof, wherein the receiver (2) including processing means arranged for performing the following steps:

- receiving at least a first portion of data (21) in one of the cycles (C1) and at least a second portion of data (22, 23) in a succeeding one of the cycles (C2, C3),

- determining a respective time of receipt (73) of the first and second portion of data (21, 22, 23), and checking a checksum (13) for each of the first and second portions of data,

- in the event that the checksums (13) for the first and second portions of data (21, 22, 23) do not correspond with each other, transmitting the second portion of data (22) to the data processing device (5),

- in the event that the checksums (13) for the first and second portions of data correspond with each other, checking for the second portion of data (22, 23) whether a preset time (ta, t2) since receipt of the first portion of data (21) has elapsed, and in the event that the preset time has elapsed, transmitting the second portion of data (23) to the data processing device (5), otherwise discarding the second portion of data (22).

10. The system according to claim 9, wherein
the receiver (2) and the data processing device (5) are included in a vehicle, wherein the receiver being adapted for receiving coded traffic information (10) from an external traffic information provider and the data processing device (5) being included in a navigation system (3) of the vehicle.

Drawing