Method of processing traffic information and digital broadcast system

Abstract

A digital broadcast transmitting/receiving system and a method for processing data are disclosed. The method for processing data may enhance the receiving performance of the receiving system by performing additional coding and multiplexing processes on the traffic information data and transmitting the processed data. Thus, robustness is provided to the traffic information data, thereby enabling the data to respond strongly against the channel environment which is always under constant and vast change.

Description

This application (also known as a group forming unit) 424, a data deinterleaver 425, and a packet formatter 426.

In the digital broadcast transmitting system having the above described structure, the main data are inputted to the packet multiplexer 402. On the other hand, the traffic information data are inputted to the E-VSB pre-processor 401, which performs additional coding processes so as to enable the traffic information data to respond quickly with robustness against noise and channel change. The E-VSB randomizer 421 of the E-VSB pre-processor 401 receives the traffic information data, thereby randomizing the received data and outputting the randomized data to the RS frame encoder 422. Herein, since the E-VSB randomizer 421 randomizes the traffic information data, the randomizing process of data randomizer 403 on the traffic information in a later process may be omitted.

The RS frame encoder 422 receives the randomized traffic information data and performs at least one of an error correction coding process and an error detection coding process on the received data. Accordingly, by providing robustness to the traffic information data, the data can scatter group error that may occur due to a change in the frequency environment. Thus, the data can respond appropriately to the frequency environment which is very poor and liable to change. The RS frame multiplexer 422 also includes a process of mixing in row units many sets of traffic information data each having pre-determined size. By performing an error correction coding process on the inputted traffic information data, the RS frame encoder 422 adds data required for the error correction and, then, performs an error detection coding process, thereby adding data required for the error detection process.

The error correction coding uses the RS coding method, and the error detection coding uses the cyclic redundancy check (CRC) coding method. When performing the RS coding process, parity data required for error correction are generated. And, when performing the CRC coding process, CRC data required for error detection are generated. More specifically, the RS frame encoder 422 identifies the traffic information data by units of a predetermined length (A). Then, a plurality of (A)-length units of traffic information data is grouped so as to form (or configure) a RS frame. Thereafter, an RS coding process is performed in at least one of a row direction and a column direction on the newly configured RS frame. In the present invention, the predetermined length unit (A) corresponds to 187 bytes.

If the inputted traffic information data correspond to a 188-byte unit MPEG transport stream (TS) packet, the first MPEG synchronization byte is removed, so as to form a 187-byte unit packet. Herein, the MPEG synchronization byte is removed because all traffic information data packets are given the same value. The MPEG synchronization byte may also be removed during the randomizing process on the E-VSB randomizer 421. In this case, the process of removing the MPEG synchronization byte performed by the RS frame encoder 422 is omitted. More specifically, if the inputted traffic information data does not include a fixed byte that can be removed, or if the length of the inputted packet is not 187 bytes, the inputted traffic information data is distinguished by 187-byte units. Thereafter, a plurality of 187-byte units of traffic information data is grouped so as to form (or configure) a RS frame. Thereafter, an RS coding process is performed in at least one of a row direction and a column direction on the newly configured RS frame.

Depending upon the channel situation between the transmission and the reception, an error may be included in the RS frame. When such error occurs, the CRC data (or CRC code or CRC checksum) may be used for checking whether an error exists by each row unit. In order to generate (or create) the CRC checksum, the RS frame encoder 422 performs CRC coding on the RS-coded traffic information data. The CRC checksum created by the CRC coding process may be used for notifying whether a damage has occurred by an error while the traffic information data are being transmitted through a channel. In the present invention, error detection coding method other than the CRC coding method may be used. Alternatively, an error correction coding method may be used in order to enhance the overall error correction ability of the receiving end.

The traffic information data sets RS-coded and CRC-coded, as described above, are outputted to the E-VSB block processor 423. The E-VSB block processor 423 codes the RS-coded and CRC-coded traffic information data at a coding rate of G/H (wherein G and H are integers, and G<H) and then outputs the G/H-rate coded data to the group formatter 424. For example, if 1 bit of the input data is coded to 2 bits and outputted, then G is equal to 1 and H is equal to 2 (i.e., G=1 and H=2). Alternatively, if 1 bit of the input data is coded to 4 bits and outputted, then G is equal to 1 and H is equal to 4 (i.e., G=1 and H=4).

An example performing a coding process at a coding rate of 1/2 (also referred to as a 1/2-rate coding process) or a coding process at a coding rate of 1/4 (also referred to as a 1/4-rate coding process) on the traffic information data is given in the description of the present invention. More specifically, in case of performing the 1/2-rate coding process, the E-VSB block processor 423 receives 1 bit and codes the received 1 bit to 2 bits (i.e., 1 symbol). Then, the E-VSB block processor 423 outputs the processed 2 bits (or 1 symbol). On the other hand, in case of performing the 1/4-rate coding process, the E-VSB block processor 423 receives 1 bit and codes the received 1 bit to 4 bits (i.e., 2 symbols). Then, the E-VSB block processor 423 outputs the processed 4 bits (or 2 symbols). At this point, in case of performing the 1/4-rate coding process, the symbol coded at a 1/2 coding rate may be repeated twice so as to output 2 symbols, or the input data may be coded twice at a 1/2 coding rate so as to output 2 symbols.

The 1/4-rate coding process may provide more enhanced error correction ability, due to the higher coding rate as compared to the 1/2-rate coding process. For this reason, the data coded at a 1/4 coding rate by the group formatter 424 in a later process are allocated to locations (or positions) in which the channel may affect the performance. On the other hand, the data coded at a 1/2 coding rate are allocated to locations having better performance. Thus, a difference in performance may be decreased. The above-mentioned 1/2-coding rate and 1/4 coding rate are only exemplary embodiments proposed in the description of the present invention, and the coding rate may vary depending upon either the selection of the coded symbols or the number of repetition.

The group formatter 424 inserts the traffic information data outputted from the E-VSB block processor 423 in a corresponding area within a data group formed according to a pre-defined rule. Also, the group formatter 424 inserts various place holders related to data interleaving or known data sets to a corresponding area within the data group. At this point, the data group may be described by at least one hierarchical area. And, depending upon the characteristic of each hierarchical area, the data type being allocated to each area may also vary.

FIG. 14A illustrates a data structure of data groups prior to the data deinterleaving process, and FIG. 14B illustrates a data structure of data groups after the data deinterleaving process. FIG. 14A illustrates an example of a data group within a data structure prior to the data deinterleaving, the data group being divided into three hierarchical areas: a head area, a body area, and a tail area. Accordingly, in the data group that is inputted for the data deinterleaving process, data are first inputted to the head area, then inputted to the body area, and inputted finally to the tail area. The three areas described above are only exemplary to facilitate the understanding of the present invention. Depending upon the design of the system designer, the areas may be described in a smaller number of areas or a larger number of areas. Further, the data being inserted in each area may also vary. Therefore, the present invention is not limited only to the example proposed herein.

As described above, the head, body, and tail areas have been given as an example to simplify the description of the present invention. Additionally, in the example shown in FIG. 14A, the data group is set to have head, body, and tail areas so that the body area is defined as the area which is not mixed with the main data area within the data group. The data group is divided into a plurality of areas so that each area may be used differently. More specifically, the area that is not interfered by the main data has a highly resistant receiving performance as compared to the area that is interfered by the main data. Furthermore, when using a system inserting and transmitting the known data to the data group, and when a long and continuous set of known data is to be inserted periodically in the enhanced data, a predetermined length of known data may be periodically inserted in the body area. However, since the main data may be mixed in the head and tail areas, it is difficult to periodically insert the known data, and it is also difficult to insert a long and continuous set of known data.

Assuming that the data group is allocated to a plurality of hierarchical areas, as shown in FIG. 14A, the above-described E-VSB block processor 423 may code the data that are to be inserted in each area, according to the characteristic of each hierarchical area, at different coding rates. In the example of the present invention, the receiving system uses different coding rates based on areas in which it is assumed that performance may vary after performing an equalization process using channel information that may be used for channel equalization.

For example, the traffic information data that are to be inserted in the body area are 1/2-rate coded by the E-VSB block processor 423, and such 1/2-rate coded traffic information data are inserted to the body area by the group formatter 424. Additionally, the traffic information data that are to be inserted in the head and tail areas are 1/4-rate coded by the E-VSB block processor 423. Herein, the 1/4-rate coding provides greater error correction performance as compared to 1/2-rate coding. Thereafter, 1/4-rate coded traffic information data are inserted to the head and tail areas by the group formatter 424. Alternatively, the traffic information data that are to be inserted in the head and tail areas may be coded by the E-VSB block processor 423 at a coding rate providing more efficient error correction performance. Subsequently, such coded traffic information data are inserted in the head and tail areas by the E-VSB block processor 423, or such coded data may be stored in a reserve area for future usage.

As shown in FIG. 14A, apart from the traffic information data coded and outputted from the E-VSB block processor 423, the group formatter 424 also inserts an MPEG header place holder, a non-systematic RS parity place holder, and a main data place holder in relation with the data deinterleaving. Referring to FIG. 14A, the main data place is allocated because the traffic information data and the main data are alternately mixed in the head and tail areas based upon the input of the data deinterleaver. In the output data that have been data deinterleaved, the place holder for the MPEG header is allocated to the very beginning of each packet.

The group formatter 424 either inserts the known data generated by a pre-decided method in a corresponding area, or inserts a known data place holder in a corresponding area so as to insert the known data in a later process. Moreover, a place holder for initializing the trellis encoder 407 is inserted in the corresponding area. For example, the initialization data place holder may be inserted in front of the known data sequence. The output of the group formatter 424 is inputted to the data deinterleaver 425. The data deinterleaver 425 performs an inverse process of the data interleaver on the data within the data group and the place holder outputted from the group formatter 424. And, then, the data deinterleaver 425 outputs the deinterleaved data to the packet formatter 426. More specifically, when the data within the data group and the place holder the configuration shown in FIG. 14A are deinterleaved by the data deinterleaver 425, the data group being outputted to the packet formatter 426 has the structure (or configuration) shown in FIG. 14B.

Among the deinterleaved and inputted data, the packet formatter 426 removes the main data place holder and the RS parity place holder that have been allocated for the deinterleaving process. Then, the packet formatter 426 groups the remaining portion of the input data and inserts the remaining data to the 4-byte MPEG header place holder in the MPEG header. Furthermore, when the known data place holder is inserted by the group formatter 424, the packet formatter 426 may insert the known data in the known data place holder. Alternatively, the known data place holder may be directly outputted without any modification for the replacement insertion in a later process.

Thereafter, the packet formatter 426 configures the data within the data group packet that is formatted as described above, as a 188-byte unit traffic information data packet. Then, the packet formatter 426 provides the configured 188-byte unit traffic information data packet to the packet multiplexer 402. The packet multiplexer 402 multiplexes the 188-byte traffic information data packet and the main data packet outputted from the packet formatter 426 according to a predefined multiplexing method. Then, the multiplexed packets are outputted to the data randomizer 403. The multiplexing method may be altered or modified by various factors in the design of the system.

In a multiplexing method of the packet multiplexer 402, a traffic information data burst section and a main data section are distinguished (or identified) along a time axis, then the two sections are set to be repeated alternately. At this point, in the traffic information data burst section, at least one of the data groups may be transmitted, and only the main data may be transmitted in the main data section. In the traffic information data burst section, the main data may also be transmitted. When the traffic information data are transmitted in the above-described burst structure, the digital broadcast receiving system receiving only the traffic information data may turn on the power only during the data burst section. Alternatively, in the main data section whereby only the main data are transmitted, the power is turned off during the main data section, thereby preventing the main data from being received. Thus, excessive power consumption of the digital broadcast receiving system may be reduced or prevented. As described above, the packet multiplexer 402 receives the main data packet and the data group, which is outputted from the packet formatter 426, and transmits the received packets in a burst structure.

When the inputted data correspond to the main data packet, the data randomizer 403 performs a randomizing process identical to that of the conventional randomizer. More specifically, the MPEG synchronization byte within the main data packet is discarded (or deleted). Then, the remaining 187 bytes are randomized by using a pseudo random byte generated from within the data randomizer 403. Subsequently, the randomized data bytes are outputted to the RS encoder 404.

However, when the inputted data correspond to the traffic information data packet, the MPEG synchronization byte among the 4 bytes inserted in the traffic information data packet by the packet formatter 426 is discarded (or deleted) and only the remaining 3 bytes are randomized. The remaining portion of the traffic information data excluding the MPEG header is not randomized and outputted directly to the RS encoder 404. This is because a randomizing process has already been performed on the traffic information data by the E-VSB randomizer 421. The RS encoder 404 RS-codes the data randomized by the data randomizer 403 or the data bypassing the data randomizer 403. Then, the RS encoder 404 adds a 20-byte RS parity to the coded data, thereby outputting the RS-parity-added data to the data interleaver 405.

At this point, if the inputted data correspond to the main data packet, the RS encoder 404 performs a systematic RS-coding process identical to that of the conventional ATSC VSB system on the inputted data, thereby adding the 20-byte RS parity at the end of the 187-byte data. Alternatively, if the inputted data correspond to the traffic information data packet, each place of the 20 parity bytes is decided within the packet. Thereafter, the 20 bytes of RS parity gained by performing the non-systematic RS-coding are respectively inserted in the decided parity byte places. The data interleaver 405 receives the data having the parity added by the RS encoder 404 and interleaves the received data. Thereafter, the data interleaver 405 outputs the interleaved data to the backward compatibility processor 406 and the trellis encoder 407. Herein, the data interleaver 405 corresponds to a byte unit convolutional interleaver.

Meanwhile, a memory within the trellis encoder 407 should first be initialized in order to allow the output data of the trellis encoder 407 so as to become the known data defined based upon an agreement between the receiver and the transmitter. More specifically, the memory of the trellis encoder 407 should first be initialized before the known data sequence being inputted is trellis-encoded. At this point, the beginning of the known data sequence that is inputted corresponds to the initialization data place holder inserted by the group formatter 424 and not the actual known data. Therefore, a process of generating initialization data right before the trellis-encoding of the known data sequence being inputted and a process of replacing the initialization data place holder of the corresponding trellis encoder memory with the newly generated initialization data are required. This is to ensure the backward-compatibility with the conventional receiving system.

The trellis memory initialization data generated to replace the initialization data place holder are decided based upon the current status of the memory within the trellis encoder 407 and the desired initialization status. Further, due to the replaced initialization data, a process of recalculating the RS parity of the corresponding data packet and a process of replacing the newly calculated RS parity with the RS parity outputted from the data interleaver 405 are required. Therefore, the backward compatibility processor 406 receives the traffic information data packet including the initialization data place holder that is to be replaced with the initialization data from the data interleaver.

Subsequently, the backward compatibility processor 406 receives the initialization data from the trellis encoder 407. Then, the backward compatibility processor 406 calculates a new non-systematic RS parity and outputs the newly calculated non-systematic RS parity to the trellis encoder 407. Thereafter, the trellis encoder 405 selects the output of the data interleaver 405 as the data within the traffic information data packet including the initialization data place holder that is to be replaced. The trellis encoder 405 also selects the output of the backward compatibility processor 406. Accordingly, the trellis encoder 405 trellis-encodes the selected outputs by symbol units. More specifically, the trellis encoder 407 trellis-encodes the initialization data instead of the initialization data place holder included in the traffic information data packet which has been inputted.

Meanwhile, when the main data packet is inputted or when the traffic information data packet is inputted, wherein the traffic information data packet does not include the initialization data place holder that is to be replaced, the trellis encoder 407 selects the data outputted from the data interleaver 405 and the RS parity, thereby performing a trellis-encoding process by symbol units. Then, the data trellis-encoded by the trellis encoder 407 are inputted to the frame multiplexer 408. The frame multiplexer 408 inserts field and segment synchronization signals in the output of the trellis encoder 407 and outputs the processed data to the pilot inserter 409. The pilot inserter 409 adds a pilot signal to the output symbol sequence of the frame multiplexer 408. The pilot-added symbol sequence is modulated to a 8VSB signal of an intermediate frequency band and, then, converted to a RF band signal, thereby being transmitted through the antenna.

Meanwhile, the embodiment shown in FIG. 13 for the components and positioning of the components of the E-VSB pre-processor 401 is merely an example for the simplicity of the description of the present invention. According to a second embodiment of the present invention, the E-VSB pre-processor 401 includes a RS frame encoder, an E-VSB randomizer, an E-VSB block processor, a group formatter, a data interleaver, and a packet formatter. The difference between the second embodiment and the E-VSB pre-processor shown in FIG. 13 is the positioning order of the RS frame multiplexer and the E-VSB randomizer. More specifically, in the second embodiment of the present invention, RS frame coding is first performed on the traffic information data, and then the data randomizing process is performed. Apart from this detail, the remaining structure of the second embodiment is identical to the embodiment shown in FIG. 13. Therefore, a detailed description of the same will be omitted for simplicity.

In a third embodiment of the present invention, the E-VSB pre-processor 401 includes a RS frame encoder, an E-VSB randomizer, a group formatter, an E-VSB block processor, a data interleaver, and a packet formatter. The difference between the third embodiment and the E-VSB pre-processor shown in FIG. 13 is the positioning order of the RS frame multiplexer and the E-VSB randomizer and, also, positioning order of the group formatter and the E-VSB block processor. More specifically, in E-VSB pre-processor according to the third embodiment of the present invention, RS frame coding is first performed on the traffic information data, and then the data randomizing and byte expansion processes are performed. Thereafter, group formatting, E-VSB block processing, data randomizing, and packet formatting processes are sequentially performed on the byte-expanded traffic information data.

In this case, since the group formatter is positioned before the E-VSB block processor, a byte expansion process needs to be performed before the group formatter in order to correspond to the coding process of the E-VSB block processor, thereby enabling the group formatter to operate without trouble. Therefore, the E-VSB randomizer not only randomizes the traffic information data but also performs byte expansion by inserting null data bits. Furthermore, the E-VSB block processor performs one of a 1/2-rate coding process and a 1/4-rate coding process on only the valid data of the byte-expanded traffic information data, which correspond to the data bits having the actual information. As described above, the E-VSB pre-processor 401 performing additional coding processes on the traffic information data may be applied in various methods. Thus, the present invention is not limited only to the examples given in the description set forth herein.

Second Embodiment

FIG. 15 illustrates a block view showing a structure of a digital broadcast transmitting system according to a second embodiment of the present invention. Referring to FIG. 15, the digital broadcast transmitting system includes an E-VSB pre-processor 501, a packet multiplexer 502, a data randomizer 503, an E-VSB post-processor 504, a RS encoder 505, a data interleaver 506, a backward compatibility processor 507, a trellis encoder 508, a frame multiplexer 509, a pilot inserter 510, a VSB modulator 511, and a RF up-converter 512. Herein, as shown in FIG. 16, the E-VSB pre-processor 501 includes a RS frame encoder 521, an E-VSB randomizer 522, a group formatter 523, a data deinterleaver 524, and a packet formatter 525. Further, as shown in FIG. 17, the E-VSB post-processor 504 includes RS parity place holder inserter 531, data interleaver 532, an E-VSB block processor 533, data deinterleaver 534, and a RS parity place holder remover 535.

In the digital broadcast transmitting system according to the second embodiment of the present invention having the above described structure, the main data are inputted to the packet multiplexer 502. On the other hand, the traffic information data are inputted to the E-VSB pre-processor 501, which performs additional coding processes so as to enable the traffic information data to respond quickly with robustness against noise and channel change.

The RS frame encoder 521 of the E-VSB pre-processor 501 receives the randomized traffic information data and performs at least one of an error correction coding process and an error detection coding process on the received data. Accordingly, by providing robustness to the traffic information data, the data can scatter group error that may occur due to a change in the frequency environment. Thus, the data can respond appropriately to the frequency environment which is very poor and liable to change. The RS frame multiplexer 521 also includes a process of mixing in row units many sets of traffic information data each having pre-determined size. The error correction coding uses the RS coding method, and the error detection coding uses the cyclic redundancy check (CRC) coding method. When performing the RS coding process, parity data required for error correction are generated. And, when performing the CRC coding process, CRC data required for error detection are generated.

In the RS frame encoder 521, the process of creating the RS frame creating process and the process of performing error correction coding and error detection coding on the created RS frame are identical to those of the RS frame encoder 422 shown in FIG. 13. Therefore, a detailed description of the same will be omitted for simplicity. The traffic information data coded by the RS frame encoder 521 are inputted to the E-VSB randomizer/byte expander 522. The E-VSB randomizer/byte expander 522 receives the coded traffic information data and performs data randomizing and byte expansion processes thereon.

At this point, since the E-VSB randomizer/byte expander 522 already performs a randomizing process on the traffic information data, the process of randomizing the traffic information by the data randomizer 503 at a later end may be omitted for simplicity. Further, the order of performing the data randomizing process and the byte expansion process may be altered. More specifically, the byte expansion process may be performed after the data randomizing process. Alternatively, the data randomizing process may be performed after the byte expansion process. The order may be selected while taking into consideration the overall system and its structure.

The byte expansion may differ depending upon the coding rate of the E-VSB block processor 533 within the E-VSB post-processor 504. More specifically, when the coding rate of E-VSB block processor 533 is G/H, the byte expander expands G bytes to H bytes (wherein G and H are integers, and G<H). For example, if the coding rate if 1/2, 1 data byte is expanded to 2 data bytes. Alternatively, if the coding rate if 1/4, 1 data byte is expanded to 4 data bytes. Then, the traffic information data outputted from the E-VSB randomizer/byte expander 522 is inputted to the group formatter 523. The operations of the group formatter 523, data deinterleaver 524, and the packet formatter 525 within the E-VSB pre-processor 501 are similar to those the group formatter 424, data deinterleaver 425, and the packet formatter 426 within the E-VSB pre-processor 401 shown in FIG. 12. Therefore, a detailed description of the same will be omitted for simplicity.

The traffic information data packet pre-processed by the E-VSB pre-processor 501 is inputted to the packet multiplexer 502 so as to be multiplexed with the main data packet. The data multiplexed and outputted from the packet multiplexer 502 are data randomized by the data randomizer 503 and, then, inputted to the E-VSB post-processor 504. Herein, the operations of the packet multiplexer 502 and data randomizer 503 are identical to those shown in FIG. 12, and therefore a detailed description of the same will be omitted for simplicity. Hereinafter, the E-VSB post-processor 504 will now be described in detail.

More specifically, the data randomized by the data randomizer 503 or bypassing the data randomizer 503 are inputted the RS parity place holder inserter 531 of the E-VSB post-processor 504. When the inputted data correspond to a 187-byte main data packet, the RS parity place holder inserter 531 inserts a 20-byte RS parity place holder at the back of the 187-byte data, thereby outputting the processed data to the data interleaver 532. Alternatively, when the inputted data correspond to a 187-byte traffic information data packet, the RS parity place holder inserter 531 inserts a 20-byte RS parity place holder within the data packet in order to perform a non-systematic RS-coding process in a later end. Thereafter, in the remaining portion of the 187 byte places bytes are inserted in the traffic information data packet, which are then outputted to the data interleaver 532.

The data interleaver 532 performs a data interleaving process on the output of the RS parity place holder inserter 531 and, then, outputs the processed data to the E-VSB block processor 533. The E-VSB block processor 533 performs additional coding processes on the valid data among the traffic information data being outputted from data interleaver 532. For example, if 1 byte has been expanded to 2 bytes by inserting null bits between data bits from the E-VSB randomizer/byte expander 522, the E-VSB block processor 533 1/2-rate codes only the valid data bit among the symbol configured of a null bit and a valid data bit and, then, outputs the processed data. On the other hand, if 1 byte has been expanded to 4 bytes by inserting null bits between data bits from the E-VSB randomizer/byte expander 522, the E-VSB block processor 533 1/4-rate codes only the valid data bit among the symbol configured of 3 null bits and 1 valid data bit and, then, outputs the processed data.

Either the main data or the RS parity place holder directly bypasses the E-VSB randomizer/byte expander 522. Also, the known data and the initialization data place holder may directly bypass the E-VSB randomizer/byte expander 522. In case of the known data place holder, the known data generated from the E-VSB block processor 533 may be outputted instead of the known data place holder. The data being coded, replaced, and bypassed from the E-VSB block processor 533 are inputted to the data deinterleaver 534. The data deinterleaver 534 performs an inverse process of the data interleaver 532, whereby a data deinterleaving process is performed on the input data, which are then outputted to the RS parity place holder remover 535.

The RS parity place holder remover 535 removes the 20-byte RS parity place holder inserted by the RS parity place holder inserter 531 for the operations of the data interleaver 532 and the data deinterleaver 534 and, then, outputs the processed data to the RS encoder 505. At this point, if the inputted data correspond to main data packet, the last 20 bytes of RS parity place holders are removed from the 207 bytes of the main data packet. Alternatively, if the inputted data correspond to the traffic information data packet, the 20 bytes of RS parity place holders are removed from the 207 bytes of the traffic information data packet in order to perform the non-systematic RS-coding process.

As another embodiment of the E-VSB post-processor 504, if the inputted data correspond to the 187-byte main data packet, the RS parity place holder inserter 531 may perform a systematic RS-coding process so as to insert a 20-byte RS parity at the end of the 187-byte main data. Accordingly, the RS parity place holder inserter 531 removes the last 20 bytes of RS parity from the 207 bytes of the main data packet. Meanwhile, the RS encoder 505, the data interleaver 506, the backward compatibility processor 507, the trellis encoder 508, the frame multiplexer 509, the pilot inserter 510, the VSB modulator 511, and the RF up-converter 512 which are provided behind the E-VSB post-processor 504 are identical to those shown in FIG. 12. Therefore, a detailed description of the same will be omitted for simplicity.

Third Embodiment

FIG. 18 illustrates a block view showing a structure of a digital broadcast transmitting system according to a third embodiment of the present invention. Referring to FIG. 18, the digital broadcast transmitting system includes an E-VSB pre-processor 601, a packet multiplexer 602, a data randomizer 603, a RS encoder 604, a data interleaver 605, an E-VSB post-processor 606, a backward compatibility processor 607, a trellis encoder 608, a frame multiplexer 609, a pilot inserter 610, a VSB modulator 611, and a RF up-converter 612.

In the digital broadcast transmitting system according to the third embodiment of the present invention having the above described structure, the main data are inputted to the packet multiplexer 602. On the other hand, the traffic information data are inputted to the E-VSB pre-processor 601, which performs additional coding processes so as to enable the traffic information data to respond quickly with robustness against noise and channel change. The structure and operation of each component of the E-VSB pre-processor 601 are identical to those of the E-VSB pre-processor 501 shown in FIG. 16. Therefore, a detail description of the same will be omitted for simplicity.

The traffic information data packet pre-processed by the E-VSB pre-processor 601 is inputted to the packet multiplexer 602 so as to be multiplexed with the main data packet. The multiplexed data outputted from the packet multiplexer 602 are data randomized by the data randomizer 603 and, then, inputted to the RS encoder 604. The packet multiplexer 602 multiplexes the main data packet and the traffic information data packet according to a pre-defined multiplexing rule. At this point, the main data packet and the traffic information data packet may be multiplexed to have burst structures as shown in FIG. 12. Furthermore, if the traffic information data have been data randomized by the E-VSB pre-processor 601, then the data randomizing process on the traffic information data performed by the data randomizer 603 may be omitted.

The RS encoder 604 RS-codes the data being randomized from or bypassing the data randomizer 603, thereby adding a 20-byte RS parity and outputting the processed data to the data interleaver 605. At this point, if the inputted data correspond to the main data packet, the RS encoder 604 performs a systematic RS-coding process identical to that of the conventional ATSC VSB system on the input data, thereby adding a 20-byte RS parity at the end of the 187-byte data. Conversely, if the inputted data correspond to the traffic information data packet, the RS encoder 604 first decides 20 parity byte places and, then, performs a non-systematic RS-coding process on the decided parity byte places, thereby inserting the 20 bytes of non-systematic RS parity in the traffic information data packet.

The non-systematic coding process is performed on the traffic information data packet because, when the value of the traffic information data is changed by the E-VSB post-processor 606, the process of which will be described in detail in a later process, the RS parity is required to be recalculated. And, at this point, the parity bytes should be outputted later than the traffic information data bytes at the output end of the data interleaver 605. The data interleaver 605 receives the data having parity added thereto by the RS encoder 604. Then, after performing an interleaving process, the data interleaver 605 outputs the processed data to the E-VSB post-processor 606 and the backward compatibility processor 607. Herein, the data interleaver 605 receives the RS parity newly recalculated and outputted from the backward compatibility processor 607, thereby outputting the received RS parity instead of non-systematic RS parity which is not yet outputted.

The E-VSB post-processor 606 performs additional coding processes in symbol units only on the traffic information data being outputted from the data interleaver 605. For example, if 1 byte has been expanded to 2 bytes by inserting null bits between data bits from the E-VSB pre-processor 606, the E-VSB post-processor 606 1/2-rate codes only the valid data bit among the symbol configured of a null bit and a valid data bit and, then, outputs the processed data. On the other hand, if 1 byte has been expanded to 4 bytes by inserting null bits between data bits from the E-VSB pre-processor 601, the E-VSB post-processor 606 1/4-rate codes only the valid data bit among the symbol configured of 3 null bits and 1 valid data bit and, then, outputs the processed data.

The main data or the RS parity being outputted from the data interleaver 605 directly bypass (or bypasses) the E-VSB post-processor 606. Moreover, the known data and initialization data place holder also directly bypass (or bypasses) the E-VSB post-processor 606. At this point, the known data place holder may be replaced with the known data generated from the E-VSB post-processor 606 and then outputted. Furthermore, the E-VSB post-processor 606 generates initialization data so as to initialize the memory within the trellis encoder 608 to a decided status at the beginning of a known data sequence. Thereafter, the initialization data generated from the E-VSB post-processor 606 is outputted instead of the initialization data place holder. Accordingly, the value of the memory within the trellis encoder 608 should be received from the E-VSB post-processor 606.

The backward compatibility processor 607 calculates the 20-byte non-systematic RS parity corresponding to the traffic information data packet configured on 187 data bytes and outputted from the E-VSB post-processor 606. Subsequently, the calculated non-systematic RS parity is outputted to the data interleaver 605. The data interleaver 605 receives the RS parity bytes calculated and outputted from the backward compatibility processor 607 and, then, outputs the received RS parity bytes instead of the non-systematic RS parity. Herein, the backward compatibility processor 607 performs a non-systematic RS-coding process because the E-VSB post-processor 606 changes the values of the traffic information data and the initialization data place holder. Accordingly, when a decoding process is performed by the conventional ATSC VSB receiver, a decoding error may be prevented. In other words, this process is performed to provide backward compatibility to the conventional ATSC VSB receiver.

The data that are additionally coded and replaced by the E-VSB post-processor 606 and that bypass the E-VSB post-processor 606 are inputted to the trellis encoder 608 so as to be trellis-encoded. Thereafter, the trellis-encoded data sequentially pass through the frame multiplexer 609, the pilot inserter 610, the VSB modulator 611, and the RF up-converter 612. Meanwhile, according to another embodiment of the present invention, initialization data, which are generated for initializing a memory within the trellis encoder 608, are generated from the trellis encoder 608 instead of the E-VSB post-processor 606. In this case, the backward compatibility processor 607 receives a traffic information data packet from the E-VSB post-processor 606 in order to calculate the parity value. Herein, the traffic information data packet includes an initialization data place holder that is to be replaced by the initialization data. Further, the backward compatibility processor 607 receives the initialization data from the trellis encoder 608. Thereafter, the calculated non-systematic RS parity is outputted to the trellis encoder 608. The remaining processes that may follow are identical to those shown in FIG. 12. Therefore, a detailed description of the same will be omitted for simplicity. Furthermore, the frame multiplexer 609, the pilot inserter 610, the VSB modulator 611, and the RF up-converter 612 are also identical to those shown in FIG. 12. Therefore, a detailed description of the same will also be omitted for simplicity.

FIG. 19 illustrates a block view of a digital broadcast receiving system according to an embodiment of the present invention. More specifically, FIG. 19 illustrates a block view showing an example of a digital broadcast receiving system that can receive traffic information data being transmitted from a transmitting system and that demodulates and equalizes the received data, thereby recovering the processed data to its initial state. Referring to FIG. 19, the receiving system includes a tuner 701, a demodulator 702, a demultiplexer 703, an audio decoder 704, a video decoder 705, a native TV application manager 706, a channel manager 707, a channel map 708, a first memory 709, a data decoder 710, a second memory 711, a system manager 712, a data broadcasting application manager 713, and a GPS module 714. Herein, the first memory 709 corresponds to a non-volatile memory (NVRAM) (or a flash memory).

The tuner 701 tunes a frequency of a particular channel through any one of an antenna, a cable, and a satellite, thereby down-converting the tuned frequency to an intermediate frequency (IF) signal. Thereafter, the down converted signal is outputted to the demodulator 702. At this point, the tuner 701 is controlled by the channel manager 707. The result and strength of the broadcast signal corresponding to the tuned channel are reported to the channel manager 707. Herein, the data being received through the frequency of a particular channel include the main data, the enhanced data, and the table data which are used for decoding the main data and enhanced data. In the example given in the present invention, traffic information data and a traffic information providing table may be applied to the enhanced data.

The demodulator 702 performs VSB demodulation and channel equalization processes on the signal outputted from the tuner 701. Then, after identifying the main data and the traffic information data from the signal, the demodulator 702 outputs the data (or signal) by TS packet units. The structure and operation of the demodulator 702 will be described in detail in a later process. In the example of the present invention, only the traffic information data packet outputted from the demodulator 702 is inputted to the demultiplexer 703. In other words, the main data packet may be inputted to another demultiplexer (not shown) that processes main data packets. Furthermore, the present invention may also be designed in a way that the demultiplexer 703 also demultiplexes the enhanced data packet as well as the main data packet. In the description of the present invention, the receiving and processing of traffic information data are described in detail. And, it should be noted that a detailed description of the processing of main data starting from the demultiplexer 703 may be omitted.

The demultiplexer 703 demultiplexes the traffic information messages and the PSI/PSIP tables from the traffic information data packets being inputted based upon the control of the data decoder 710. Thereafter, the demultiplexed traffic information messages and PSI/PSIP tables are outputted to the data decoder 710 in a section format. In an example given in the present invention, a traffic information message carried by a payload within the TS packet is outputted in a DSM-CC section format. At this point, the demultiplexer 703 performs a section filtering process based upon the control of the data decoder 710 so as to delete duplicate sections and to output only the non-duplicate sections to the data decoder 710. Moreover, the demultiplexer 703 may output the section configuring a desired table (e.g., VCT) through a section filtering process to the data decoder 710. Herein, the VCT includes traffic information descriptors shown in FIG. 9. The traffic information descriptors may also be included in the PMT.

The section filtering method includes a method of initiating section filtering after verifying the PID of a table defined by the MGT (e.g., VCT), and, when the VCT has a fixed PID (i.e., a base PID), a method of initiating section filtering without verifying the MGT. At this point, the demultiplexer 703 performs section filtering by referring to the table_id field, the version_number field, the section_number field, and so on. The data decoder 710 parses the DSM-CC section configuring the demultiplexed traffic information message. Then, the data decoder 710 decodes the traffic information message being a result of the parsing process and, then stores the traffic information message in a database of the second memory 711. The data decoder 710 groups a plurality of sections having the same table identifiers (table_id) to configure and parse a table. Then, the data decoder 710 stores the system information being the parsed result in the database of the second memory 711.

The second memory 711 is a table and data carousel database storing system information parsed from the tables and traffic information messages parsed from the DSM-CC section. Whether or not a table is configured of a single section or a plurality of sections can be known by the table_id field, the section_number field, and the last_section_number field within the table. For example, grouping only the TS packets having the PID of the VCT having table identifiers allocated to the VCT becomes the VCT.

When parsing the VCT, information on the virtual channel to which traffic information is transmitted may be obtained. In addition, supplemental information associated with the traffic information message described, as shown in FIG. 9, in the traffic information descriptors included in the VCT may also be obtained. More specifically, when parsing the traffic information descriptors, application identification information, service component identification information, service information (e.g., service name, service description, service logo, subscriber information, free text information, help information, etc.), and so on, of the traffic information message being transmitted to the corresponding virtual channel can be obtained.

The application identification information, service component identification information, and service information of the traffic information message obtained as described above may either be stored in the second memory 711 or outputted to the data broadcasting application manager 713. Additionally, reference may be made to the application identification information, service component identification information, and service information for decoding the traffic information message. Alternatively, the application identification information, service component identification information, and service information may also be used for preparing the operation of the application program for the traffic information message.

The data decoder 710 controls the demultiplexing of the system information table corresponding to the table associated with channel and event information. Thereafter, the data decoder 710 can transmit an A/V PID list to the channel manager 707. The channel manager 707 may refer to the channel map 708 to send a request (or command) for receiving an information table associated with the system, and then the channel manager 707 can receive the corresponding result. The channel manager 707 may also control the channel tuning of the tuner 701. Furthermore, the channel manager 707 directly controls the demultiplexer 703 so as to directly set up the A/V PID, thereby controlling the audio and video decoders 704 and 705.

The audio and video decoders 704 and 705 may respectively decode and output the audio and video data demultiplexed from the main data packet, or respectively decode and output the audio and video data demultiplexed from the traffic information data packet. Meanwhile, according to the embodiment of the present invention, it is apparent that when traffic information data and also audio data and video data are included in the enhanced data, the audio data and video data demultiplexed by the demultiplexer 703 may be respectively decoded by the audio decoder 704 and the video decoder 705. For example, the audio decoder 704 may decode the audio data by using an audio coding (AC)-3 decoding algorithm, and the video decoder 705 may decode the video data by using an MPEG-2 decoding algorithm.

Meanwhile, the native TV application manager 706 operates a native application program stored in the first memory 709, thereby performing general functions such as channel switching. The native application program refers to a software that is being mounted upon shipping of the receiving system. More specifically, when a user request is transmitted to the receiving system through a user interface (UI), the native TV application manager 706 the request onto the screen through a graphic user interface (GUI), thereby responding to the user request. The user interface receives the user request through an inputting device, such as a remote controller, a key pad, a jog dial, and a touch screen provided on the display screen. Thereafter, the user interface outputs the received user request to the native TV application manager 706, the data broadcasting application manager 713, and so on.

The native TV application manager 706 controls the channel manager 707, thereby controlling channel associated operations, such as managing the channel map 708 and controlling the data decoder 710. In addition, the native TV application manager 706 stores the GUI control of the general receiving system, the user request, and the status of the receiving system to the first memory 709, and also recovers the information stored in the first memory 709. The channel manager 707 controls the tuner 701 and the data decoder 710, thereby managing the channel map 708 so as to be able to respond to the channel request made by the user.

More specifically, the channel manager 707 sends a request to the data decoder 710 so that the table associated with the channel, which is to be tuned, can be parsed. Thereafter, the channel manager 707 receives a report on the parsing result of the corresponding table from the data decoder 710. Then, depending upon the reported parsing result, the channel manager 707 updates the channel map 708. The channel manager 707 also sets up a PID to the demultiplexer 703 so as to demultiplex the table associated with the traffic information message from the traffic information data. The system manager 712 controls booting of the receiving system by turning on and off the power and, then, stores a ROM image (including downloaded software images) to the first memory 709. In other words, the first memory 709 stores operation programs, such as operation system (OS) programs required for operating the receiving system, and application programs performing data service functions.

The application program is a program that processes the traffic information message stored in the second memory 711, thereby providing the traffic information service to the user. If a data broadcasting data type other than the traffic information data is stored in the second memory 711, the corresponding data are processed by the application program or another type of application program and, then, provided to the user. The operation program and application program stored in the first memory 709 may be updated or corrected with a newly downloaded program. Furthermore, since the stored operation program and application program are not deleted even when the driving power supply is shut down, when the driving power is supplied, the program can be performed without having to download a new program.

The application program for providing the traffic information service according to the present invention may be mounted in the first memory 709 upon shipping of the receiving system, or stored later on in the first memory 709 after being downloaded. Also, the application program for the traffic information service (i.e., traffic information providing application program) that is stored in the first memory 709 can be deleted, updated, and corrected. Furthermore, the traffic information providing application program may also be downloaded along with the traffic information data and executed each time the traffic information data are being received.

When a data service request is made through the user interface, the data broadcasting application manager 713 operates the corresponding application program stored in the first memory 709 so as to process the requested data, thereby providing the requested data service to the user. And, in order to provide such data service, the data broadcasting application manager 713 supports the GUI. Herein, the data service is provided in the form of text, voice, graphic, still image, motion picture, and so on. The data broadcasting application manager 713 may be provided with a platform for executing the application program stored in the first memory 709. The platform may be, for example, a Java virtual machine for executing a Java program.

Hereinafter, an example of providing traffic information service to the user by having the data broadcasting application manager 713 execute the traffic information providing application program stored in the first memory 709 and, then, process the traffic information message stored in the second memory 711 will now be described in detail. The traffic information service according to the present invention is provided to the users by a receiver having only one or none of an electronic map and a GPS mounted therein in the form of at least one of a text, a voice, a graphic, a still image, and a motion picture. If the GPS module 714 is mounted on the receiving system shown in FIG. 19, the GPS module 714 receives satellite signals transmitted from a plurality of low earth orbit satellites so as to extract a current location information (i.e., longitude, latitude, altitude), thereby outputting the extracted information to the data broadcasting application manager 713. At this point, it is assumed that the electronic map including information on each link and node and the various graphic information are stored in a storage unit (or memory) other than the first memory 709 or the second memory 711.

By executing the traffic information providing application program, the data broadcasting application manager 713 provides the traffic information service requested by the user based upon the current location information acquired from the GPS module 714 and the traffic information message stored in the second memory 711. More specifically, based upon the request of the data broadcasting application manager 713, the traffic information message stored in the second memory 711 is read and inputted to the data broadcasting application manager 713. The data broadcasting application manager 713 analyses the traffic information message read from the second memory 711, thereby extracting required information and/or control signals in accordance with the contents of the message. In the description of the present invention, it is assumed that a request for a CTT service has been made by the user.

More specifically, the data broadcasting application manager 713 extracts date/time and message generation time included in the message management container of each TPEG message and determines if the following container is a CTT status container based on ‘message element’ information (i.e. an identifier). If it is determined that the following container is a CTT status container, the data broadcasting application manager 713 provides the information extracted from the CTT component included in the CTT status container. The data broadcasting application manager 713 may display congestion and/or travel time status and predicted congestion and/or travel time status, which will be described below. The information extracted from the CTT component may include determining, based on identifiers, that the traffic information includes a message management container including status information within various message components within the message management container. The components may each include different status information associated with different links or locations and identifiers associated with the different status information. The containers and components may each include information associated with a generation time, version number, data length, and identifiers of included information.

In the implementations of FIGS. 6a to 6d, information, e.g., length of average speed on a link included in each status component may be regarded by information of ID 1 written in the common data component template within the stored common data component element, and data may be as the information of ID 1 indicates. A similar process may be applicable to other information, for example, link travel time, predicted average speed and so on.

The data broadcasting application manager 713 then extracts information on the link location for which the previously extracted information is intended from the following TPEG location container. In implementations described with respect to FIGS. 6a to 6d, length information for link identifier (Link ID) carried in a link component may be obtained from the stored common data component element. A similar process may be applied to other components that use common data component element. The position information may be, for example, the coordinates (i.e., latitudes and longitudes) of the start and end positions or an ID that is uniquely assigned to each link, depending on the type of the TPEG location container. If the terminal is equipped with the second memory 711, The data broadcasting application manager 713 finds the location of the link for which the received traffic information is intended with reference to the information on each link and node stored in the second memory 711. If necessary, the data broadcasting application manager 713 may convert the coordinates of a link into a link ID or vice versa.

The data broadcasting application manager 713 reads a part of the electronic map centered around the position coordinates received from the GPS module 714, and displays the read electronic map data on a display screen. In this case, a specific graphic sign is displayed at a specific point corresponding to the current location.

The data broadcasting application manager 713 displays the average link speed at a location corresponding to the coordinates or link ID delivered via the TPEG location container following the container delivering the average link speed. There are various processes for the data broadcasting application manager 713 to display the traffic information.

For example, the data broadcasting application manager 713 may show links in different colors. For example, if the road on the image is determined to a current road, the red color is indicative of 0 to 10 km per hour, the orange color is indicative of 10 to 20 km per hour, the green color is indicative of 20 to 40 km per hour, and the blue color is indicative of at least 40 km per hour. If the congestion change information has a specific value “1” or “2”, a character string (“Increase” or “Reduction”) or icon assigned to the specific value “1” or “2” may also be displayed on a corresponding link along with the congestion change information. If the congestion change information has a specific value “0” or “3”, a displayed status is not updated to a new status, such that a current displayed status remains. If the congestion acceleration tendency is received in the form of the rate of change of the average speed, the data broadcasting application manager 713 displays the value only when a request from the user is received to prevent visual confusion of the user. The rate of change may be displayed together for a user-chosen route or a front link.

If the terminal does not include the second memory unit 711 equipped with the electronic map, an average link speed associated with only a forward link of a current traveling path may be displayed in different colors, or may be displayed in different numerals. If the route of the vehicle with the terminal installed is determined, the terminal may show the average speed at the links included in the determined route instead of the links located in front of the current position.

The data broadcasting application manager 713, responsive to user input, may display the link travel time, the link delay, and the congestion type instead of or simultaneously with the average link speed.

If the user requests predicted congestion and/or travel time status, the data broadcasting application manager 713 displays the predicted average link speed at each link in colors or in numbers instead of the current average link speed. In this case, the colors or numbers describing the predicted status may be displayed simultaneously with the current average link speed but the location or used colors may be different. If the user switches the display mode to see the predicted link travel time instead of the predicted average link speed, the data broadcasting application manager 713 displays the predicted link travel time on the electronic map or graphics on a display screen.

If the data broadcasting application manager 713 is capable of routing, the data broadcasting application manager 713 may search or research the desirable route based on the received predicted average link speed or predicted link travel time. For example, the data broadcasting application manager 713 finds the shortest time path to the destination by using the predicted link average time or predicted link travel time at each link to be reached 30 minutes later at the current speed.

If the terminal is equipped with a voice output capability, the terminal may audibly output the received predicted status or congestion tendency information for a specified link or links.

The information and/or control signals are temporarily stored in the rewritable memory and used by the data broadcasting application manager 713. After using the information stored in the memory, the data broadcasting application manager 713 may store the average link speed or link travel time at intervals of, such as, for example, 20 minutes (e.g., 1:00, 1:20, 1:40) for the last 1 hour. The interval of storage may differ depending on the storage capacity of the memory. By automatically expiring the information from within memory, the system may be assured that it is working with recent information when consulting the contents of the memory, and thus may be able to represent information as current with confidence without having to otherwise maintain or check information reflecting when the stored data was collected/aggregated/stored.

If a specific link is selected by the user while the average speed at each link is stored in the memory, the data broadcasting application manager 713 controls a display screen so that the history of the average link speed or the history of the link travel time at the specified link is displayed as a graph. The link name is received along with the coordinates of the link or link ID through the TPEG location container or included in the electronic map stored in the second memory 711. The current congestion status, predicted congestion status, or other status may be displayed in other or different ways.

If the predicted congestion status is not included in the received traffic information, the data broadcasting application manager 713 may predict the average speed using the current average speed and the history of the average link speed stored in the memory, and displays the predicted average link speed. The method for predicting the average link speed may be the same as the aforementioned prediction method executed in the traffic information provider.

FIG. 20 illustrates a flow chart showing process steps of receiving and processing traffic information data according to an embodiment of the present invention. Referring to FIG. 20, a method of processing traffic information data according to the present invention will now be described in detail. More specifically, when the power of the receiving system is turned on (S721), and when a channel selection or channel switching is inputted (S722), a received channel signal is tuned to a physical frequency so as to correspond to the selected or switched channel by using the channel map (S723). Herein, the channel selection or channel switching is performed in accordance with a user command or a system command.

At this point, the traffic information data having the traffic information message and the system information multiplexed therein may be received through the channel frequency tuned as described above. If the traffic information data are received (S724), the demultiplexer 703 may demultiplex the traffic information message and system information tables by using PID extraction and section filtering (S725). Among the system information, tables associated with channel information include the VCT or the PAT/PMT. Herein, at least one of the PMT and VCT may include the traffic information descriptor(s) according to the present invention. By parsing the system information table, information on the virtual channel can be obtained, and whether an A/V element stream is being transmitted to the corresponding virtual channel and whether the traffic information data are being transmitted can be known. If the traffic information data are transmitted to the virtual channel, an application identifier, a service component identifier, and service information can be acquired by parsing the traffic information descriptor.

More specifically, information on the virtual channel is extracted by referring to an element stream type (ES type) and PID within the system information table (i.e., VCT and/or PAT/PMT) (S726). If the channel information extracted from the system information table indicates that an A/V ES exists within the virtual channel (S727), an A/V PID of the corresponding virtual channel in the channel map is set up (S728), thereby performing A/V demultiplexing and decoding (S729). Therefore, the user can view the broadcast program corresponding to the A/V (S730). Meanwhile, if it is indicated in Step 727 that an A/V ES does not exist in the virtual channel, the present invention verifies when the traffic information data are being transmitted to the virtual channel (S731).

A plurality of methods for verifying whether the traffic information data have been transmitted to the virtual channel may be proposed. For example, verification can be performed by parsing the system information table, and verification can also be performed by using the PID within the TS packet. When assuming that the traffic information data have been transmitted to the DSM-CC section, the existence (or presence) of the traffic information data can be known by parsing the field value of any one of the stream_type field within the PMT and the stream_type field of the service location descriptor within the VCT. In other words, if the stream_type field value is ‘0x95’, this indicates that the traffic information data have been transmitted to the corresponding virtual channel. Therefore, if it is verified in Step 731 that the traffic information data are being transmitted to the virtual channel, all traffic information having the DSM-CC data format that are being transmitted to the virtual channel are received (S732), thereby providing the traffic information service desired (or requested) by the user (S733).

If it is verified, in Step 731, that neither the A/V ES nor the traffic information data exist in the virtual channel, then the corresponding virtual channel is determined to be an invalid channel. In this case, the system may display, for example, a message that no valid channel or signal exists (S736). Thereafter, the process is returned to Step 724 in order to newly receive a valid channel information table.

Meanwhile, the system verifies whether a request for changing (or switching) the channel is made during the data service or while viewing a broadcast program (S734). If a change in channel has been requested, and if the request corresponds to changing the virtual channel, the data broadcasting process is reset, and the process is returned to Step 726 in order to find a new set of virtual channel information. Further, if the request corresponds to changing the physical channel, the process is returned to Step 723 so as to tune to the corresponding physical channel.

However, if there is no request for changing the channel, the system verifies whether a channel information version has been upgraded (S735). If it is determined in Step 735 that the channel information version has been upgraded, this indicates that the channel information has been changed (or modified) by the broadcast station. Therefore, the process is returned to Step 724 in order to receive a new channel information table. Conversely, if it is determined in Step 735 that the channel information has not been changed (or modified), then viewing of the broadcast program may be resumed.

The demodulator (reference numeral 702 of FIG. 19) according to the present invention uses the known data information that is inputted to a traffic information data section and, then, transmitted by a transmitting system so as to perform process such as carrier wave synchronization recovery, frame synchronization recovery, channel equalization, and so on. Thus, the receiving performance can be enhanced. FIG. 21 and FIG. 22 respectively illustrate detailed block views of the demodulator shown in FIG. 19.

Referring to FIG. 21, the demodulator includes a VSB demodulator 761, an equalizer 762, a known sequence (or data) detector 763, an E-VSB block decoder 764, an E-VSB data processor 765, and a main data processor 766. More specifically, an intermediate frequency (IF) signal of a channel frequency tuned by the tuner 701 (shown in FIG. 19) is inputted to the VSB demodulator 761 and the known sequence detector 763. The VSB demodulator 761 performs self gain control, carrier wave recovery, and timing recovery processes on the inputted IF signal, thereby modifying the IF signal to a baseband signal. Then, the VSB demodulator 761 outputs the newly created baseband signal to the equalizer 762 and the known sequence detector 763. The equalizer 762 compensates the distortion of the channel included in the demodulated signal and then outputs the error-compensated signal to the E-VSB block decoder 764.

At this point, the known sequence detector 763 detects the known sequence location inserted by the transmitting end from the input/output data of the VSB demodulator 761 (i.e., the data prior to the demodulation or the data after the modulation). Thereafter, the location information along with the symbol sequence of the known data, which are generated from the detected location, is outputted to the VSB demodulator 761 and the equalizer 762. Further, the known sequence detector 763 outputs information related to the traffic information data additionally coded by the transmitting end and the main data that have not been additionally coded to the E-VSB block decoder 764. Herein, the information allowing the traffic information data and the main data to be differentiated (or identified) by the E-VSB block decoder 764 is outputted to the E-VSB block decoder 764. Although the connection state is not shown in FIG. 21, the information detected by the known sequence detector 763 may be used throughout almost the entire receiving system. Herein, the detected information may also be used in the E-VSB data deformatter 765-1 and in the RS frame decoder 765-2.

The VSB demodulator 761 uses the known data symbol sequence during the timing and/or carrier recovery, thereby enhancing the demodulating performance. Similarly, the equalizer 762 uses the known data sequence, thereby enhancing the equalizing performance. Furthermore, the decoding result of the E-VSB block decoder 764 may also be fed-back to the equalizer 762, thereby enhancing the equalizing performance. Meanwhile, when the data being inputted to the E-VSB block decoder 764, after being equalized by the equalizer 762, correspond to the traffic information data being additionally coded and trellis-encoded by the transmitting end, the equalizer 762 performs an inverse process of the transmitting end by additionally decoding and trellis-decoding the inputted enhanced data. On the other hand, when the data being inputted correspond to the main data being trellis-encoded only and not additionally coded, the equalizer 762 only performs trellis-decoding on the inputted main data.

The data group decoded by the E-VSB block decoder 764 is outputted to the E-VSB data processor 765, and the main data packet is outputted to the main data processor 766. More specifically, when the inputted data correspond to the main data, the E-VSB block decoder 764 performs Viterbi-decoding on the input data so as to output a hard decision value or to perform hard decision on a soft decision value and output the hard-decided result. Meanwhile, when the inputted data correspond to the traffic information data, the E-VSB decoder 764 outputs a hard decision value or a soft decision value on the inputted enhanced value.

More specifically, when the inputted data correspond to the traffic information data, the E-VSB block decoder 764 performs a decoding process on the data encoded by the E-VSB block processor and the trellis encoder of the transmitting system. At this point, the data outputted from the RS frame encoder of the E-VSB pre-processor included in the transmitting system may correspond to an external code, and the data outputted from each of the E-VSB block processor and the trellis encoder may correspond to an internal code. When decoding such concatenated codes, the decoder of the internal code should output a soft decision value, so that the external coding performance can be enhanced. Therefore, the E-VSB block decoder 764 may output a hard decision value on the traffic information data. However, it is more advantageous to output a soft decision value.

As an example of the present invention, the E-VSB data processor 765 includes an E-VSB data deformatter 765-1, a RS frame decoder 765-2, and an E-VSB derandomizer 765-3. It would be efficient to apply this structure in the E-VSB pre-processor of the transmitting system (shown in FIG. 13) which includes an E-VSBG randomizer, a RS frame encoder, an E-VSB block processor, a group formatter, a data deinterleaver, and a packet formatter. The main data processor 766 includes a data deinterleaver 766-1, a RS decoder 766-2, and a data derandomizer 766-3.

Herein, the data deinterleaver 766-1, the RS decoder 766-2, and the data derandomizer 766-3 included in the main data processor 766 are blocks required for receiving the main data. Therefore, these blocks may not be required in the structure of the receiving system that only receives the traffic information data. The data deinterleaver 766-1 performs an inverse process of the data interleaver included in the transmitting end. More specifically, the data deinterleaver 766-1 deinterleaves the main data being outputted from the E-VSB block decoder 764 and outputs the deinterleaved data to the RS decoder 766-2.

The RS decoder 766-2 performs systematic RS decoding on the deinterleaved data and outputs the RS-decoded data to the data derandomizer 766-3. The data derandomizer 766-3 receives the output of the RS decoder 766-2 and generates a pseudo random data byte identical to that of the randomizer included in the transmitting system. Thereafter, the data derandomizer 766-3 performs a bitwise exclusive OR (XOR) operation on the generated pseudo random data byte, thereby inserting the MPEG synchronization bytes to the beginning of each packet so as to output the data in 188-byte main data packet units. At this point, the output of the data derandomizer 766-3 may be inputted to the demultiplexer 703 shown in FIG. 19. Alternatively, the output of the data derandomizer 766-3 may be inputted to a main data specific demultiplexer (not shown), which demultiplexes the A/V data and channel information associated tables from the main data.

The data being outputted from the E-VSB block decoder 764 are inputted to the E-VSB data deformatter 765-1 in a data group form. At this point, the E-VSB data deformatter 765-1 already knows the configuration of the input data group. Accordingly, the E-VSB data deformatter 765-1 removes the main data, the known data that have been inserted in the data group, the trellis initialization data, the MPEG header, and the RS parity added by the RS encoder of the transmitting system that all were inserted in the main data group. Thereafter, the E-VSB data deformatter 765-1 outputs only the traffic information data to the RS frame decoder 765-2. More specifically, the RS frame decoder 765-2 receives only the traffic information data RS-coded and/or CRC-coded by the E-VSB data deformatter 765-1.

The RS frame decoder 765-2 performs an inverse process of the RS frame encoder included in the transmitting system. Accordingly, the RS frame decoder 765-2 corrects the errors within the RS frame. Thereafter, the RS frame decoder 765-2 adds a 1-byte MPEG synchronization byte, which was removed during a RS frame coding process, to the error-corrected traffic information data packet. Then, the processed data are outputted to the E-VSB data derandomizer 766-3. At this point, if a row permutation process was performed on the traffic information data, an inverse row permutation process is also required. The E-VSB data derandomizer 766-3 performs a derandomizing process, which corresponds to an inverse process of the E-VSB randomizer included in the transmitting system, on the inputted traffic information data and outputs the processed data. Thus, the transmitting system can receive the transmitted traffic information data.

Meanwhile, if the E-VSB randomizer is positioned after the RS frame encoder in the structure of the E-VSB pre-processor included in the transmitting system, the E-VSB data processor may include only the E-VSB data deformatter and the RS frame decoder. In this case, the operation of the E-VSB data deformatter becomes partially different from that of the E-VSB data deformatter shown in FIG. 21. In other words, the difference between the E-VSB data deformatter of FIG. 21 and the above-described E-VSB data deformatter is that a derandomizing process is first performed on the traffic information data, and the RS frame decoding process is performed afterwards.

In this case, only the data derandomizing process may be performed, or the data derandomizing process may be processed along with the null data removing process. This may differ depending upon the structure and operation of the E-VSB pre-processor included in the transmitting system. More specifically, only the data derandomizing process may be performed, or the data derandomizing process and the null data removing process may both be processed depending upon the positioning order of the E-VSB block processor and the group formatter, and whether the coding process was performed only on the valid data by the E-VSB block processor.

For example, if the E-VSB block processor is positioned before the group formatter in the E-VSB pre-processor, the receiving system does not require. the null data to be removed, since byte expansion has not been performed. In addition, even though a byte expansion process has been performed, if the E-VSB block processor has performed an additional coding process only on the valid data (e.g., if the coding process was performed at a coding rate of 1/2 or at a coding rate of 1/4), the receiving system does not require the process of removing the null data. Conversely, if the E-VSB block processor is positioned after the group formatter in the E-VSB pre-processor, the receiving system requires a byte expansion process to be performed. In this case, if the E-VSB block processor has performed an additional coding process all data types (e.g., if the coding process was performed at a coding rate of 1/2 or at a coding rate of 1/4), the receiving system requires the null data to be removed.

However, if the removal of the expanded byte is required, the order of the byte removal process and the derandomizing process may vary depending upon the structure of the transmitting system. More specifically, if the byte expansion is performed after the randomizing process in the transmitting system, then the byte removal process is first performed before performing the derandomizing process in the receiving system. Conversely, if the order of the process is changed in the transmitting system, the order of the respective processes in the receiving system is also changed.

When performing the derandomizing process, if the RS frame decoder requires a soft decision in a later process, and if, therefore, the E-VSB block decoder receives a soft decision value it is difficult to perform an XOR operation between the soft decision and the pseudo random bit, which is used for the derandomizing process. Accordingly, when an XOR operation is performed between the pseudo random bit and the soft decision value of the traffic information data bit, and when the pseudo random bit is equal to ‘1’, the E-VSB data deformatter changes the code of the soft decision value and then outputs the changed code. On the other hand, if the pseudo random bit is equal to ‘0’, the E-VSB data deformatter outputs the soft decision value without any change in the code. Thus, the state of the soft decision may be maintained and transmitted to the RS frame decoder.

If the pseudo random bit is equal to ‘1’ as described above, the code of the soft decision value is changed because, when an XOR operation is performed between the pseudo random bit and the input data in the randomizer of the transmitter, and when the pseudo random bit is equal to ‘1’, the code of the output data bit becomes the opposite of the input data (i.e., 0 XOR 1=1 and 1 XOR 0=0). More specifically, if the pseudo random bit generated from the E-VSB packet deformatter is equal to ‘1’, and when an XOR operation is performed on the hard decision value of the traffic information data bit, the XOR-operated value becomes the opposite value of the hard decision value. Therefore, when the soft decision value is outputted, a code opposite to that of the soft decision value is outputted.

Accordingly, the RS frame decoder performs an inverse process of the RS frame encoder included in the transmitting system. Therefore, the RS frame decoder corrects the errors within the RS frame. Subsequently, the RS frame decoder adds a 1-byte MPEG synchronization byte, which was removed during a RS frame coding process, to the error-corrected traffic information data packet. Thus, the initial traffic information data transmitted by the transmitting system can be obtained.

FIG. 22 illustrates a detailed block view of the demodulator according to a second embodiment of the present invention. Referring to FIG. 22, the demodulator includes a VSB demodulator 781, an equalizer 782, a known sequence (or data) detector 783, a Viterbi decoder 784, a data deinterleaver 785, a RS decoder 786, a data derandomizer 787, and an E-VSB data processor 788. Herein, the E-VSB data processor 788 includes a main data packet remover 788-1, an E-VSB packet deformatter 788-2, and an E-VSB data processor 788-3. It would be efficient to apply the demodulator shown in FIG. 22 to the transmitting system having the structure shown in FIG. 18. Furthermore, the VSB demodulator 781, the equalizer 782, and the known sequence detector 783 are identical to those shown in FIG. 21. Therefore, since reference can be made for the structure of the same components, a detailed description of the same will be omitted for simplicity.

The Viterbi decoder 784 Viterbi-decodes the data outputted from the equalizer 782 and converts the Viterbi decoded data to bytes. Thereafter, the converted data are outputted to the data deinterleaver 785. The data deinterleaver 785 performs an inverse process of the data interleaver of the transmitting system and outputs the deinterleaved data to the RS decoder 786. If the received data packet is the main data packet, the RS decoder 786 RS-decodes the received main data packet. Alternatively, if the received data packet is the traffic information data packet, the RS decoder 786 removes the non-systematic RS parity bytes and outputs the processed data to the data derandomizer 787.

The data derandomizer 787 performs an inverse process of the randomizer of the transmitting system on the output of the RS decoder 786. Thereafter, the data derandomizer 787 inserts the MPEG synchronization byte in the beginning of each packet, thereby outputting the data in 188-byte packet units. The output of the data derandomizer 787 is simultaneously outputted to the demultiplexer 703 (shown in FIG. 19) or the main data specific demultiplexer (not shown) and outputted to the main data packet remover 788-1 of the E-VSB data processor 788.

The main data packet remover 788-1 removes the 188-byte main data packet from the data outputted from the data derandomizer 787 and outputs the processed data to the E-VSB packet deformatter 788-2. The E-VSB packet deformatter 788-2 removes the 4-byte MPEG header, known data, and trellis initialization data from the 188-byte data packet. Then, the E-VSB packet deformatter 788-2 outputs only the traffic information data to the E-VSB data processor 788-3. At this point, the E-VSB packet deformatter 788-2 may or may not remove the null data.

More specifically, when the E-VSB post-processor of the transmitting system shown in FIG. 18 performs additional coding on the traffic information data, and, accordingly, when the coding is performed only on the valid traffic information data, the removing of the null data is not required. Conversely, however, if the additional coding process is performed on all byte-expanded traffic information data, the null data must be removed. The E-VSB data processor 788-3 performs an inverse process of the E-VSB pre-processor included in the transmitting system on the output of the E-VSB packet deformatter 788-2. Thus, the traffic information data initially transmitted from the transmitting system may be obtained.

As described above, the digital broadcast transmitting/receiving system and the method for processing data are advantageous in that when receiving traffic information data through a channel, the data are robust against error and are compatible with the conventional VSB receiver. Furthermore, data can be received more efficiently without error even in channels having severe noise and ghost effect.

In addition, by performing additional error correction coding and error detection coding processes on the traffic information data and transmitting the processed data, robustness is provided to the traffic information data, thereby allowing the data to respond appropriately to the changes in the channel environment. Furthermore, by using link identifiers for providing the traffic information data, the transmission capacity may be minimized. And, by warning in advance the information on heavy congested traffic status, the amount of traffic may be adequately dispersed, thereby allowing the roads to be circulated efficiently. The present invention having the above-described advantages may be more efficiently used when applied in mobile and portable receiver which requires a greater degree of robustness against noise and ghost effect.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the inventions. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

1. A digital broadcast transmitter, comprising:

a pre-processor pre-processing enhanced data, the pre-processor comprising:

an rs frame encoder encoding the enhanced data using a Reed-Solomon scheme;

a block-processor encoding the rs-encoded enhanced data at a coding rate of 1/2 or 1/4;

a group forming unit forming a data group including the enhanced data and known data, the data group including a first, a second and a third region, the second region being positioned between the first and third regions, the first and third regions including the enhanced data, placeholders for main data and rs parity bytes, and the second region including the enhanced data and placeholders for mpeg header bytes and rs parity bytes, wherein at least one row of the data group comprises of only the known data;

a data de-interleaver de-interleaving data in the data group; and

a packet formatter forming enhanced data packets including the de-interleaved data by adding header data to the deinterleaved data;

a multiplexer multiplexing the enhanced data with one or more main audio and video data;

an encoder performing non-systematic rs encoding on the enhanced data packets and adding first parity data to the rs-encoded enhanced data;

an interleaver interleaving data in the non-systematic rs encoded enhanced data packets;

a trellis encoder having at least one memory and trellis-encoding the interleaved data, the at least one memory being initialized by initialization data when the interleaved data correspond to a beginning of at least one known data sequence; and

a data transmission unit inserting synchronization data into the trellis-encoded data, modulating the trellis-encoded data having the synchronization data, and transmitting the modulated data.

2. The digital broadcast transmitter of claim 1, wherein the group forming unit further inserts initialization data location holders into the data group.

3. The digital broadcast transmitter of claim 1, wherein the pre-processor further comprises a randomizer configured to randomize the enhanced data.

4. A method of processing enhanced data in a digital broadcast transmitter, the method comprising:

pre-processing the enhanced data, the with a pre-processor, the pre-processing comprising:

an rs frame encoder encoding the enhanced data with an rs frame encoder using a Reed-Solomon scheme;

a block-processor encoding the rs-encoded enhanced data with a block processor at a coding rate of 1/2 or 1/4;

a group forming unit forming a data group including the enhanced data and known data with a group forming unit, the data group including a first, a second and a third region, the second region being positioned between the first and third regions, the first and third regions including the enhanced data, placeholders for main data and rs parity bytes, and the second region including the enhanced data and placeholders for mpeg header bytes and rs parity bytes, wherein at least one row of the data group comprises of only the known data;

a data de-interleaver de-interleaving data in the data group with a data de-interleaver; and

a packet formatter forming enhanced data packets including the de-interleaved data by adding header data to the deinterleaved de-interleaved data with a packet formatter;

a multiplexer multiplexing the enhanced data with one or more main audio and video data with a multiplexer;

non-systematic Reed-Solomon (rs) encoding on the enhanced data packets;

interleaving data in the non-systematic rs encoded enhanced data packets;

trellis-encoding the interleaved data, wherein at least one memory included in a trellis-encoder being initialized by initialization data when the interleaved data correspond to a beginning of at least one known data sequence; and transmitting through a data transmission unit by inserting synchronization data into the trellis-encoded data, modulating the trellis-encoded data having the synchronization data, and transmitting the modulated data.

5. The method of claim 4, wherein the group forming unit further inserts initialization data location holders are inserted into the formed data group by the group forming unit.

6. The method of claim 4, wherein pre-processing further comprises randomizing the enhanced data.

7. The digital broadcast transmitter of claim 1, wherein the modulated data include an identifier of a data unit.

8. The method of claim 4, wherein the modulated data include an identifier of a data unit.