KR100865789B1 - Robust Data Expansion for 8kHz Signals - Google Patents

Abstract

Robust data extension is added to a standard 8VSB digital television transmission system by encoding high priority data packets in a rate 1/2 trellis encoder. The high priority data 1/2 trellis encoded packet is multiplexed with the normal data packet and entered into the general data service of an 8VSB system with further rate 2/3 trellis encoder. Combined trellis encoding results in rate 1/3 trellis encoding for robust data packets and rate 2/3 trellis encoding for normal data. The rate 1/3 trellis encoding provides nearly equivalent robustness to the 2VSB signal while maintaining the backward compatibility of the 8VSB signal. Four legacy requirements are met for backward compatibility with receivers and transmitters that conform to existing ATSC. 1) The coefficient of the symbol set for robust data transmission is the same as the 8VSB signal. 2) Compatibility with the existing trellis encoder and decoder is maintained. 3) The Reed Solomon parity byte indicates that the existing receiver sends the robust data packet to the Reed Solomon parity. 4) Robust data packets are maintained as normal data so as not to flag as having errors. 4) MPEG compatibility is maintained by preventing the robust data packets from appearing as error MPEG packets that may destabilize existing MPEG decoders.

Description

ROBUST DATA EXTENSION FOR 8VSB SIGNALING}

The present invention relates to a method and apparatus for improving the robustness of a digital communication system.

The Digital Television (DTV) transmission format of the American Television Standards Committee (ATSC) uses 8-level residual sideband (8VSB) technology in which each successive three-bit symbol is transmitted as one of eight possible signal amplitudes. In a 4VSB system, each successive two bit symbol is transmitted as one of four possible signal amplitudes. In a 2VSB system, each successive 1-bit symbol is transmitted as one of two possible signal amplitudes. The 2VSB (or 4VSB) signal is more robust than the 8VSB signal because the distance between the allowable signal levels is greater, making the transmission signal less susceptible to noise burst and signal distortion.

It is desirable to add robust extensions to the ATSC transmission format so that TV stations can serve both the HDTV fixed receiver market and the portable market. At the same time, there is a proposal to add a "training packet" to the ATSC signal to improve the reception of the current DTV signal inside the ATSC. The ATSC format is primarily designed for fixed reception and is not currently optimized for robust reception. The current proposal for robust mode of the ATSC standard was to use only 2VSB signal mode during robust transmission. Unfortunately, the 2VSB signal mode is not backward compatible with the existing 8VSB format for several reasons. First of all, the two-level signal obsoletes the current generation of improved demodulator ICs that use blind equalization techniques. When the original ATSC format was adopted, it was considered that the training sequence that occurs every 24ms is sufficient to track static multipath and dynamic multipath. Extensive field-tests have determined that the repetition rate of the training sequence is too low to track dynamic multipath. The tracking problem of dynamic multipath changes occurring less than 24ms has been partially solved by many new generation receivers by using blind equalization to obtain VSB signals. One kind of particularly effective blind equalization is the Constant Modulus Algorithm (CMA). CMA uses a third order error function that effectively "opens the eye" so that decision directed equalization can be used. Since the q-element is the Hilbert transform of the real part, the CMA error function used in the VSB is only a real value signal because the received symbol in the slicer is only real. The introduction of 2VSB symbols interspersed with 8VSB symbols causes the CMA error function to be mismatched. The detailed reason for the discrepancy is outlined below.

The 8 VSB symbol set is {-7, -5, -3, -1, 1, 3, 5, 7}. In order for the 2VSB signal to be backward compatible when operating in decision directed mode, the transmit symbol must be bipolar and come from the 8VSB set. The natural selection is {+5, -5}, but when using blind equalization such as CMA, it can be shown that this selected symbol set, as well as other anode sets from the 8VSB set, is incompatible with the 8VSB set itself. Incompatibility occurs because the phase coefficient for the 2VSB symbol is different from the phase coefficient required for the 8VSB symbol.

The modulus for the 8 VSB symbol is E {X ** 4} / E {X ** 2}. Where X is the transmit symbol and E is the expected value. The coefficients required to bring the received symbol to the desired level of {-7, -5, -3, -1, 3, 5, 7} so that decision directed equalization can be used are as follows.

((-7) ⁴ + (-5) ⁴ + (-3) ⁴ + (-1) ⁴ + (1) ⁴ + (3) ⁴ + (5) ⁴ + (7) ⁴ ) / ((-7 ) ² + (-5) ² + (-3) ² +

(-1) ² + (1) ² + (3) ² + (5) ² + (7) ² ) = 37

However, the coefficient for the 2 VSB symbol set {+5, -5} is as follows.

((-5) ⁴ + (5) ⁴ ) / ((-5) ² + (5) ² ) = 25

The coefficients for the 2VSB symbol set {+7, -7} are as follows.

((-7) ⁴ + (7) ⁴ ) / ((-7) ² + (7) ² ) = 49

Therefore, it can be seen that neither form of 2VSB symbol set {+5, -5} or {+7, -7} is compatible with 8VSB signals with respect to coefficient requirements for blind equalization. Thus, if a 2VSB signal shape is used with an existing (i.e. legacy) demodulator IC using 8VSB coefficients for blind equalization, the equalized symbol level will not be compatible with the level required for decision directed mode. More specifically, if the 2VSB symbols {+5, -5} are interspersed with 8VSB symbols, the equalized received symbols will be at a higher level than expected by a legacy (i.e., conventional) receiver, and the expected value of the 2VSB symbols will be This reflects the fact that it is on average lower than 8VSB symbols. The blind equalizer will then compensate for this level of inconsistency by creating a new symbol set with an effective factor of 37. Conversely, if 2VSB symbols {+7, -7} are used, the equalization symbol will be lower than expected. The discrepancy between the CMA and the decision directed symbol level is a function of the number of 2VSB symbols injected into the 8VSB symbol stream. In addition, the mismatch will result in signal acquisition failures in the presence of severe multipath and / or significant Gaussian noise and impairs significant handoff from blind to decision direction.

The introduction of training packets to help equalization reduces the payload capacity of the channel. Each 8VSB symbol has one bit of redundancy and two bits of information introduced by the trellis code. This kind of coding is called 2/3 trellis coding. Symbols from known training packets contain 0 bits of information and 3 bits of redundancy. The two extra bits come from one additional bit of trellis code and training packets known from the payload itself. This kind of symbol is called a 0/3 speed symbol. Since 0/3 speed symbols do not have information, they are only overhead and should be avoided if possible.

The present invention is directed to ATSC of information with symbols that 1) create a more robust tier of service and at the same time 2) improve the performance of the equalizer at the receiver, thereby improving the acceptability of the normal tier of service. It is embodied in compliant embedding.

In addition to creating a more robust tire of service, backward compatibility with receivers and transmitters that follow existing ATSC should be maintained. The legacy requirements of the existing ATSC standard require that the service's robust tires meet four requirements for backward compatibility.

8VSB

Robust data packets must appear at the receiver to have the characteristics of an 8VSB signal. In particular, the coefficient of the symbol set for robust data transmission should be equal to the coefficient of 8 VSB.

Trellis encoding and decoding

Robust data packets must use existing trellis decoders at the receiver and existing trellis encoders at the transmitter.

Reed Solomon coding

Robust data packets must generate valid Reed Solomon parity bytes so that existing receivers do not flag robust data packets as having a Reed Solomon parity error.

MPEG compliance

Robust data packets must maintain the MPEG format. In particular, robust data packets should not appear as error MPEG packets that may destabilize existing MPEG decoders.

All four compatibility requirements are met by the system of the present invention.

8VSB and Trellis Encoding and Decoding

Assume that one or more high priority data packets (also referred to as robust data packets) at the transmitter represent data transmitted by the robust tire of the currently added service while maintaining 8VSB and trellis encoding compatibility. The high priority data packet is first encoded in the rate 1/2 trellis encoder and multiplexed with the normal priority data packet. Additional half-rate trellis encoders and robust / general packet multiplexers represent the hardware added to existing 8VSB transmitters to implement the present invention. The half rate trellis encoded packet multiplexed with the normal packet is inserted into the unchanged data service of the existing 8VSB transmitter in synchronization with the system frame sync signal to form the transmission tire of the next robust data packet. .

Standard 8VSB systems usually include a speed 2/3 trellis encoder as part of the existing ATSC system standard. Inserting a rate 1/2 trellis encoded high priority data packet into a standard ATSC transmission system results in more high priority data packets being encoded at the rate 2/3 trellis encoder. The final result of the double trellis encoding (first half rate, then second rate) is the rate 1/3 trellis encoded signal during robust data packet transmission. A rate 1/3 trellis encoded signal transmitted at 3 bit symbol intervals of an 8VSB signal has greater robustness compared to a 1 bit 2VSB signal. At the same time, the present invention maintains 8VSB signal characteristics for all other system purposes. Thus, the benefits of the 2VSB system are achieved and backward compatibility of the 8VSB trellis encoded system is maintained.

The ATSC standard also specifies an integral pre-coding of one of the data bits (X2). Integral pre-coding results in at least 1.25dB of performance loss for robust data. Integral pre-coding first cancels or cancels the operation by differentiating the robust data. Since derivative is the inverse of the integral, the final effect is to eliminate the effect of the integral pre-coder. The advantage of deactivating the integral pre-coder during robust data transmission is that it generates systematic trellis code.

According to another aspect of the present invention, potential errors resulting from deactivation of the pre-coder are avoided by the use of selectable inversion or non-inversion of the transmission data. Errors specified as phase reversal may occur upon transition from robust to normal packet transmission. The difference between actual and calculated normal data is monitored and the difference is detected and used to activate the inverting / non-inverting circuit. Operation of the inverting / non-inverting circuit avoids potential phase errors in general data resulting from deactivation of the integral pre-coder during robust data transmission.

Reed Solomon Coding

With regard to Reed Solomon encoding compatibility, robust data packets should transmit Reed Solomon parity bytes as normal data so that existing receivers do not flag robust data packets as having Reed Solomon errors. However, sending Reed Solomon parity bytes as normal data impairs the reliability of robust data packets. In fact, robust data packets lose the benefit of Reed Solomon coding because the Reed Solomon parity byte itself is not a robust data transmission. Specifically, during the reverse transmission channel state in which normal data is not received, the Reed Solomon parity byte is not received. According to another aspect of the system of the present invention, an additional level of Reed Solomon coding is encapsulated in a robust data packet.

MPEG compliance

With regard to MPEG compliance, high priority packets are made smaller than standard MPEG data packets. In the system of the present invention, a data pre-processor adds a parity byte to the robust data packet. To ensure backward compatibility, the header bytes for robust MPEG data packets are encoded with NULL packet headers and encoded as normal data.

System with compatible robust data extension

The resulting transmit data stream contains high priority (rate 1/3 trellis encoded) data packets and multiplexed regular (rate 2/3 trellis encoded) data packets. The receiver detects the receive bit field of the standard ATSC frame sync signal and stores the receive robust mode tire control code. Frame synchronization of trellis-encoded high priority data packets allows the receiver to switch to robust mode whenever robust data packets are being received and to normal mode whenever normal data is being received. do. In robust mode, the receiver of the present invention is configured to receive received robust data packets to 1) receive more reliable data, additionally 2) adjust the equalizer more quickly to track temporary channel conditions such as dynamic multipath. use. Legacy receivers ignore the reserved bit field.

Thus, the system of the present invention adds a robust tire of service to a standard 8VSB transmitter while maintaining backward compatibility with existing 8VSB receivers. In addition, the existing unmodified 8VSB transmitter does not require internal modifications for use with the present invention other than installing additional hardware necessary for the implementation of robust tires of service. Another aspect of the invention is that symbols with new information (robust data packets) are trellis encoded such that the substate of this trellis code follows the ATSC trellis code. Another aspect of the present invention is that the ATSC trellis code is enhanced (during reception of robust data packets) to improve the reception of a generic tire (during reception of generic data packets).

Thus, in the present system, a typical tire of service includes 8VSB symbols encoded at 2/3 speed, and a robust tire of service includes 8VSB symbols encoded at 1/3 speed. ATSC training signals and segment sync symbols are encoded at 0/3 rate.

1 is a block diagram of an ATSC hierarchical transmission system for generating a two-tire symbol stream according to the present invention.

FIG. 2 is a detailed block diagram of a robust encoder and an 8VSB modulator in FIG. 1.                 

FIG. 2A is a detailed block diagram of the robust packet processor of FIG. 2.

FIG. 2B is a detailed block diagram of the inverter / non-inverter 34 of FIG. 2A.

2C is a block diagram of a robust data pre-processor in accordance with the present invention.

3 is a block diagram of a receiver capable of receiving service of two tires.

3A is a detailed block diagram of the demodulator / decoder of FIG. 3.

3B is a block diagram of a valid trellis encoder assuming all data is robust.

3C shows a trellis state transition diagram when a two-tire (robust / general) service is being transmitted.

1 illustrates an ATSC hierarchical transmission system using robust data mode. Packets encoded in robust mode are high priority data packets and are combined with the normal packets of the system by robust encoder / 8VSB modulator 10. High priority packets are assembled using a NULL packet identifier (PID) that is not valid for the normal packet stream. After processing, the signal is sent to the transmitter 11. Normal and robust data packets are broadcast over transmission channel 12. The robust receiver 13 processes the received signal to generate two packet streams (general packet stream and high priority stream). Robust receivers receive error-free high priority data packets in reverse channel conditions where normal packets cannot be used due to excessive errors. The generic receiver 14 generates a single packet stream of generic packets (if the channel condition is good enough to allow reception). Since the high priority data packet contains a packet identifier (PID) associated with an invalid NULL packet in the normal packet stream, the high priority data packet is discarded by the transport demultiplexer at the general receiver 14. This ensures backward compatibility.

Robust encoder

2 is a block diagram of a robust encoder according to the present invention. Generic MPEG 2 transport packets (denoted "general packets") are multiplexed with additional MPEG 2 transport data packets (denoted "high priority packets") in the transport MUX / tier timing generator 20. Additional data High priority data packets are encoded with a robust tier of service. Because robust data packets are encoded at a rate of 1/3, zero padding every two bit positions expands one data packet to occupy two transport packets that are not necessarily contiguous in time. The tire timing generator 20a also generates a robust / normal (N / R) signal, which synchronizes the insertion of robust symbols into the symbol stream in the robust packet processor 24. Normal data is displayed by setting N / R = 0, and robust data is displayed by setting N / R = 1.

The percentage of total usable symbol for robust encoding can vary from 0 to 100%. However, the receiver must know the percentage of robust packets to synchronize its tire timing generator to the transmitter's tire timer generator 20a. The robust mode tire control code is inserted in the reserved bit field of the ATSC signal. The receiver extracts the robust mode tire control code and uses the stored robust mode tire control code for synchronization. Because legacy receivers ignore the reserved bit field of the ATSC signal, backward compatibility is maintained.

The appropriate choice for the robust tire control code takes into account 32 distinct modes, which are indicated by 5 bits in the spare field of frame synchronization. In such a case, robust mode = 0 is defined as 0% robust data, and rover mode = 31 is defined as 100% robust data. Between 0 and 100% robust data, the percentage of symbols that can be used for robust data varies linearly with the robust mode tire control code. For example, when the robust mode tire control code is 7, 25% (8/32) of available symbols are for general data and the remaining 75% of available symbols are for robust data. In addition, for each robust mode tire control value, the position and pattern of robust data packet and frame synchronization with respect to the general data packet are predefined. When the receiver stores the robust mode tire control code, the receiver knows where to find each robust data packet in the received data stream according to the selected robust mode tire control code.

It is advantageous to add the error correction coding to the 5 robust mode tire control bits in the spare field so that the tire control code can also be robust and restored without errors. After multiplexing 20, the transport stream is encoded by virtual encoder 22.

The robust encoder / 8VSB modulator of FIG. 2 includes a virtual encoder 22 and a virtual decoder 26. Robust packet processor 24 processes the intermediate received data stream. The purpose of the virtual encoder 22 and the virtual decoder 26 is to simulate the process occurring within the existing VSB modulator 28. In that way, the hierarchical packet stream can be input to an existing VSB modulator 28. In addition to requiring access to the frame sync signal from the existing VSB modulator 28, no other changes are necessary. In the future, robust packet processor 24 may be integrated into VSB modulator 28.

The virtual encoder 22, robust packet processor 24 and virtual decoder 26 need not be three separate processes, but are described in this manner to show the steps required for ATSC compliance. By definition, the transport stream will be compliant because VSB modulator 28 conforming to (traditional) ATSC processes the transport stream. The virtual encoder 22 is an ATSC compliant and also generates a compliant VSB symbol. The VSB symbol is then modified by robust packet processor 24 and decoded by virtual decoder 26. The output of the virtual decoder 26 includes an MPEG transport stream with the service of two tires. Frame synchronization from the existing VSB modulator 28 is performed by the virtual decoder 26, the virtual encoder 22 and the transport MUX / tire timing generator 20 to synchronize the insertion of robust data packets into the appropriate timeslots. Used.

2A shows the back end of the virtual encoder 22 and the details of the robust packet processor 24. According to the standard scientific name, X1 and X2 are bits of information data to be encoded, Z2, Z1 and Z0 are trellis-encoded bits, and Y2 and Y1 are intermediate bits generated in digital signal processing.

The ATSC format specifies integral pre-coding of X2 data bits. Integral pre-coding (legacy in ATSC format) was originally intended to handle co-channel interference using a comb filter (which was obsolete by the use of modern notch filtering techniques). . It is desirable to deactivate or cancel the integral pre-coder during robust data packet transmission. The robust packet is adjusted to eliminate the integral pre-coding operation by differentiating it. Since derivative is the inverse of the integral, the final effect is to eliminate the operational effect of the integral pre-coder. If the integral pre-coder is not deactivated during robust data transmission and the integral pre-coder randomly advances the state, a loss of at least 1.25 dB occurs. Additional loss may occur because integral pre-coding of the X2 stream doubles the effective bit error rate of the decoded X2 bits at the receiver. The advantage of deactivating the integral pre-coder during robust data transmission is to generate systematic trellis code.

As shown in FIG. 2A, integral pre-coding of the X2 stream by XOR 32a and delay 30a produces a Y2 stream at virtual encoder 22. It is more convenient to modify the Y2 and Y1 data streams to produce the Z2 and Z1 data streams. The first step of robust packet processor 24 is to eliminate the effect of integral pre-coding by differentiating the Y2 stream with delay 30b and XOR 32b. The multiplexer 36 selects the differentiated Y2 data from the "0" input in response to the robust / general signal 435 asserted low. When high, the Y2 bit is selected from the "1" input to the multiplexer 36.

In fact, if the disparity is between the differentiated Y2 and Y2 bits at the time to resume normal symbol transmission, the Y2 bit is inverted at 34. The combination of the XOR 32d controlling the inverted / non-inverted block 34 ensures that the polarity of the transmitted Z2 bits is correct when transitioning the robust to a normal symbol. Inversion or non-inversion of Y2 in component 34 ensures that the differential decoder in the existing receiver operates properly to be backward compatible.

FIG. 2B is a detail of the inversion / non-inversion block 34 of FIG. 2A. As indicated, any disparity detected by XOR 32d in FIG. 2A between the differentiated Y2 and Y2 bits at the transition time from robust to normal symbol transmission is used at 34 to invert the transmit Y2 bits. . As shown in FIG. 2B, the output of the XOR 32d from FIG. 2A is delayed one symbol clock by the delay element 341 and sampled by the next robust / normal signal and held in the delay element 342. As shown in FIG. The signal held at delay element 342 is then used to invert or non-invert (Y2) at XOR 343. The output of the XOR 343 is connected to the "1" input of the MUX 36 of Figure 2A. Combined elements 341 and 342 allow any disparity that occurs at the time of the last transmit robust symbol to be used to control the inversion or non-inversion of subsequent general symbols.

Non-pre-coded X2 is coupled with the virtual decoder 26 to generate the exact same Z2 data bits for the payload portion of the bit stream present at the output of the robust packet converter. It is handled by the back to back combination of the existing 8VSB encoder. The difference still occurring between the Z2 stream at the robust packet converter output and the existing VSB modulator output is caused by the normal Reed Solomon parity bytes generated for robust data packets by the existing 8VSB encoder. The Reed Solomon byte generated by the virtual encoder follows a zero-filled packet while the Reed Solomon parity byte generated by the existing encoder follows the actual transmission packet. Since Reed Solomon parity bytes that follow ATSC are transmitted as regular data, parity bytes are more error prone than robust data messages themselves. The general encoding of parity bytes for robust packets requires that their own forward error correction (FEC) parity bytes are needed if robust data packets use Reed Solomon's correction code. According to the present invention, the robust data pre-processor adds an extra parity byte only for the robust data. Additional parity for rovers data is encapsulated in the robust data payload. An embodiment of this robust data pre-processor is described below.

As discussed above, the virtual encoder 22 of FIG. 2 predicts the symbol sequence that will actually exist at the output of the VSB modulator 28. One aspect of this prediction is to determine the state of the pre-coder at VSB modulator 28 so that integral pre-coding of the X2 data bits can be deactivated for robust data. However, it is impossible to accurately predict this state, which relies on ATSC parity bytes for robust packets that cannot be computed at this point because the states have not been calculated and the associated robust payload is still being calculated. Because.

Thus, sometimes integrated pre-coder deactivation circuits require AT SC parity bytes that have not yet been calculated for robust data packets. The final effect of this dilemma (a parity byte arriving before the information byte) is that in the worst case (approximately one in 40 robust symbols), the transmit robust data packet inverts the Z2 bits for the Z1 and Z0 bits (phase inversion). Integral pre-coder advances the state to make it work. In the latter case, the transmit code is the inverted system code. The inversion of the Z2 bits is phase ambiguity that must be resolved at the receiver.

Alternatively, the phase ambiguity can be avoided at the transmitter by changing the existing Reed Solomon code and using a non-standard Reed Solomon code. Standard Reed Solomon encoders append a parity byte to the end of the message. After interleaving, the parity byte for a particular packet comes out before every information byte comes out, causing a dilemma to eliminate the operation of the integral pre-coder circuit. In Reed Solomon encoding, the parity byte does not need to be placed at the end of the message to generate a valid Reed Solomon codeword. However, changing the Reed Solomon code at the transmitter means that the existing transmitting station needs to replace the existing 8VSB modulator. In this sense, changing Reed Solomon codes to non-standard codes is not fully backward compatible with existing ATSC broadcast equipment. Existing ATSC broadcast equipment will continue to be compatible with existing receivers. However, the replacement of 8VSB modulators is needed to take advantage of robust data transmission (robust data service and more reliable general data service).

Thus, two legacy receivers that expect the parity byte to be at the end of the message and a new receiver that knows the actual placement of the parity and information bytes will know the valid Solomon codeword. In practice, the information bytes and parity bytes are scrambled, but the legacy Reed Solomon decoder will still know this new code as a valid Reed Solomon codeword (to maintain backward compatibility). As pointed out above, the packet header in each robust data packet was given a PID corresponding to a NULL packet. Thus, it is not important for the legacy receiver that the information bytes were scrambled because the legacy receiver discards the high priority data packet as a NULL packet in any case.

Using non-standard Reed Solomon encoding, a parity byte position can be placed in a packet so that all information bytes come first after interleaving and Reid Solomon parity bytes that have not yet been computed can be calculated from previously derived information. Reed Solomon parity bytes can now be calculated prior to the parity bytes being processed by the integral pre-coder circuit, thus eliminating the phase ambiguity described above. The receivers for each of the two cases (phase ambiguities are resolved at the reception or at the transmitter) are described below.

For robust symbol encoding, the Z2 data stream is next trellis encoded to generate the Z1 data stream as shown by delayers 30c, 30d and XOR 32c in FIG. 2A. The multiplexer 38 selects between a trellis coded signal at the "0" input and a Y1 signal at the "1" input in response to the robust / normal signal. The trellis code shown is a four-state convolution feedback trellis code identical to the ATSC trellis code used to generate the Z0 bits from the Zl bit stream. In this regard, the Z1 bit stream is a trellis coded version of the Z2 bit stream. The effect of the virtual decoder 26 (FIG. 2) on the Z2 / Z1 bit stream is important for the randomizer. A virtual decoder that conforms to the ATSC intentionally derandomizes the Z2 bits, unlike the Z1 bits. The effect is to generate a Z2 / Z1 bit pair at the input of the existing VSB modulator with a pattern different from the random extraction pattern applied. Since the randomness disparity between the two bits is eliminated by the randomizer of the existing VSB modulator, the Z2 / Z1 pair at the modulator output causes the randomization parity between them to be removed, and what is present at the robust packet processor output is Z2 / Z1 bit pair.

The Z1 bit stream of the existing VSB modulator is also trellis encoded to produce the Z0 bit stream. The combined trellis encoder of the robust packet processor and the encoder in the existing VSB modulator form a valid 16 state trellis encoded sequence whose substate (Z0 bits) follows the ATSC.

The trellis encoder of the robust packet processor does not advance the state when a normal ATSC packet or robust parity byte is being transmitted. The control MUX controls whether a generic 8VSB or robust symbol is being sent. The role of the inverted / non-inverted block before MUX for the Z2 bit inverts the polarity of the Y2 bit when the 8VSB symbol transmission is recovered when the disparity exists between Y2 and the differentiated Y2 bit stream. This polarity inversion causes the Z2 bit stream to follow the ATSC when differential decoding is performed on normal ATSC symbols.                 

The trellis encoder shown was a 16-state trellis code. Trellis codes with more states can also be used. In addition, multidimensional trellis codes may be used. In particular, four-dimensional trellis code may be suitable for this application. Because no robust symbols are being transmitted so that while the super state is maintained, the worst placement of robust symbols in a frame causes the four substates in the ATSC trellis to proceed during the critical period. The first symbol at the resumption of robust transmission, because the substate code (ATSC) is less reliable and the 16 state trellis decoder must use substate evaluation from the ATSC trellis code alone when normal transmission is taking place. Is less reliable than subsequent symbols and a four-dimensional code can enhance the predictability of this first symbol.

The time of robust symbol placement is indirectly controlled by the existing VSB modulator itself. The transport MUX inserts an unencoded robust packet synchronized with the VSB field sync signal. This allows robust symbols to be placed in known positions within the VSB frame. Other patterns and robust data rates are possible but must be limited to a finite number in practice. Because the best way to send to the receiver what the batch baton was was through the use of spare bits in the field sync segment. These bits should be coded for reliable reception when operating under worst case communication channel conditions.

The robust data pre-processor (FIG. 2C) is provided to pre-process the high priority data before being applied to the robust encode / 8 VSB modulator 10 of FIG. As shown in FIG. 2 and described above, robust encoder 10a multiplexes robust data packets (also high priority packets) and normal packets in one stream. As mentioned above, for robust data packets the Reed Solomon parity byte will have significantly less reliability compared to the information byte (encoded as rovers data) encoded as normal data (for backward compatibility). Another backward compatibility issue is that the MPEG data header may be converted into a valid MPEG packet header (with a non-zero likelihood) encoded for the VSB modulator 28, thereby converting robust data packets to MPEG. Occurs when used as a packet. Error MPEG packets can destabilize existing MPEG decoders. The MPEG packet header includes four bytes, one byte of sync and three other bytes with packet identifier (PID) information. It is desirable to ensure that robust encoders do not generate valid MPEG packets corresponding to robust data for existing MPEG decoders.

The robust data preprocessor solves the two backward compatibility problems described above (Lost Solomon Encoding and Error MPEG Packets). The main idea is to consider the robust data packet to be smaller than the MPEG data packet and add a parity byte to the robust data packet and generate a robust MPEG data packet. To ensure backward compatibility, the header bytes for robust MPEG data packets are encoded with NULL packet headers and encoded as normal data.

2C illustrates the robust data preprocessor in more detail. The data preprocessor of FIG. 2C processes (more accurately pre-processes) the high priority data packet in FIG. 1 before the robust data packet is fed to the robust encoder / 8VSB modulator 10. Encoding techniques for non-MPEG packets are also described, because robust data can be used for services other than those that result in MPEG packets (eg, datacasting). For robust data consisting of MPEG packets, the MPEG standard 47hex sync bytes are removed and replaced with a FIR parity check code at 350 as described in ITU J.83 Annex B. The parity check 350 added by the robust data preprocessor of FIG. 2C enables reliable MPEG packet synchronous detection at the receiver and also error detection in the MPEG packet. If the robust data is any other (non-MPEG) protocol, step 350 passes. Information on whether robust data is composed of MPEG data or other protocol is transmitted through robust payload type information bits in the reserved bits of the VSB frame.

The next step in the robust data preprocessor is (184, 164) Reed Solomon encoder 352, which adds 20 Reed Solomon parity bytes to each 164 robust data bytes for a total of 184 bytes. The generator polynomial for the Reed Solomon encoder is the same as that used in the Reed Solomon 207, 187 8-VSB encoder (187 data bytes, 20 Reed Solomon parity bytes and 207 total bytes). The 184-byte Reed Solomon block is mapped to two 184-byte packets at step 354 as follows. When four bits are designated as A, B, C and D, a new byte is generated by spawning zero bits to produce bytes A, 0, B, 0, C, 0, D, 0. Thus, each input byte is mapped to two output bytes to double the data rate. Each 184 byte output from the Reed Solomon encoder produces two 184-byte MPEG packet payloads. A four byte MPEG NULL packet header (including 47 hex sync bytes) is appended at step 356 to generate a compliant MPEG transport stream packet. Legacy receivers ignore MPEG NULL packets that are essential for backward compatibility. The 4-byte MPEG NULL header is encoded as a normal byte (47hex sync bytes are removed by the VSB modulator). Setting the N / R (Normal / Robust) flag to 0 (Normal) for the 3-byte header ensures a generic encoding for the MPEG header. Existing receivers decode the packet headers as NULL packets, thus discarding packets corresponding to robust data. The two robust data packets generated in step 354 can be allocated consecutively in the frame (or even packets are allocated within the frame) so that the receiver accumulates two packets and performs the Reed Solomon decoding operation. .

Since some of the robust data bytes need to be encoded as normal, the virtual encoder 22 keeps track of these bytes as shown in FIG. The virtual encoder 22 is a data random extractor, a Reed Solomon encoder, a convolutional interleaver and a trellis code interleaver according to US Provisional Patent Application No. 60/280944, filed here on April 2, 2001, referred to herein as the A / 53 specification. It includes. The A / 53 specification is a proposal submitted to the Advanced Television System Committee (ATSC) of 1750K, Washington Street, DC 20035. The data randomizer is an ATSC randomizer, which operates on every byte and does not change the N / R signal other than adding a delay to account for the block's latency. The Reed Solomon encoder is an ATSC Reed Solomon 207, 187 encoder, which holds an N / R signal as provided by a data randomizer for the information bytes. For all Reed Solomon parity bytes, including robust data MPEG packets, the N / R signal is set to normal mode. The convolutional interleaver also continues to track the N / R signal corresponding to every byte output by the Reed Solomon encoder by interleaving the N / R signal. The trellis code interleaver output is a 2-bit nibble (X2, X1) and also continuously tracks an N / R signal corresponding to every byte output by the convolutional interleaver.

As described above in FIG. 2A the robust packet processor 24 operates on the next incoming data and switches between normal and robust operation in accordance with the normal / robust flag. The remainder of the block includes the virtual decoder 26. The trellis code deinterleaver outputs bytes to the convolutional deinterleaver. The convolutional deinterleaver performs a deinterleaving operation according to the A / 53 specification (US Provisional Patent Application No. 60/280944, filed April 2, 2001). The Reed Solomon decoder simply removes the parity byte for every input packet, and the derandomizer is the ATSC derandomizer.

Robust decoder

Robust decoders have a dual role. First, the robust data decoder is used to receive robust data packets in a channel state in which the normal 8VSB symbols cannot be received, and the second robust data decoder improves the reception of the normal 8VSB symbols. Both modes of operation (normal and robust) use the same decoding system. The differences in processing steps for normal and robust mode are noted below.

The system multiplexes normal and robust modes by switching between robust data packets and normal data packets. 3C shows a state transition diagram of the trellis when hierarchical transmission is present. The intervals 610 and 614 are state transitions when robust symbols are transmitted (N / R = 1), and the intervals 612 are state transitions when normal symbols are transmitted (N / R = 0). Lines in bold in section 612 indicate the presence of parallel transitions.

3 is a block diagram of a robust receiver. The improved signal is processed by the tuner 310, IF / SAW filter 312 by the general method. The modulator / decoder 314 decodes the received symbols and demultiplexes them to provide a generic packet stream for the digital television receiver 316 and a robust packet stream for the portable device 318 (previously referred to as a high priority data packet stream). ) The data packet stream may be received in a channel state in which the video packet stream cannot be received.

3A is a detailed block diagram of demodulator / decoder 314 at the receiver of FIG. The improved VSB signal is digitized by the analog-to-digital converter 320. VSB demodulator front end 324 performs matched filtering, timing and pilot reconstruction. The front end 324 also provides AGC control to the tuner and the IF gain amplifier. The frame sync detector 322 synchronizes with the frame sync signal and receives the reserved bits from the frame sync representing the 5-bit robust mode tire control code. The robust mode tire control code is stored to assemble a completed map of VSB-symbols indicating whether each symbol is robust or generic (323). The resulting N / R signal, which specifies the position of the robust symbol within the VSB frame, defines the transition between normal and robust modes, can be used from the synchronization circuit 323 to all other receiver functions. The remainder of the receiver includes a convolutional deinterleaver 330, a Reed Solomon decoder 332, and a VSB derandomizer 334 following the ATSC. Generic / robust packet separator 336 separates the generic data packet from the robust data packet. MPEG synchronization is added to the robust MPEG packet at 338. Finally, robust data post processor 340 at the receiver performs 184/164 Reed Solomon decoding, which is the reverse operation of the encoder provided by the robust data preprocessor of FIG. 2C located at the transmitting station.

Equalizer 326 is generally a DFE or decision feedback equalizer. The DFE trains the equalizer using the extra reliability of robust symbols for difficult terrestrial channels. Robust symbols provide an extra 5-6dB of training margin. It outputs a soft decision symbol and associated N / R signal to specify whether the symbol is a normal or robust symbol.

The Generic / Robust Trellis Decoder 328 is according to the A / 53 specification (US Provisional Patent Application No. 60/280944, filed Apr. 2, 2001) for generic symbols. For robust symbols, the general / robust trellis decoder 328 performs trellis decoding for the trellis code shown in FIG. 3B. As shown in FIG. 3B, robust data is encoded at the first trellis encoders 342a, 344a, 342b. The output of the first trellis encoder is further encoded at the second trellis encoders 342c, 344b, 342c. Note that the trellis decoder is interrupted by switching back and forth between the normal and robust symbols. An effective way to implement a trellis decoder in both cases is to perform a "parallel transition" to the general trellis within the scope of the robust trellis.

As mentioned above, if a systematic Reed Solomon decoder is used, there is a phase ambiguity in the symbol corresponding to the Reed Solomon parity byte for the robust data packet. Note that this ambiguity requires a decision between the two possibilities for the symbol (this results in a decision for one of the two subsets). This decision is made either symbol-based or block-based.

If a nonstandard Reed Solomon encoder is used at the transmitter, there is no phase ambiguity. Nonstandard Reed-Solomon encoders include reordering of information bytes (which must be reversed at the receiver). Since the reordering is based on the location of the packet within the only known frame at the receiver, the reordering can be easily reversed. However, as noted earlier, non-standard Reed Solomon codes are not compatible with existing transmitters and require modification of existing transmitters.

The remainder of the block in the diagram of the robust data receiver of FIG. 3A is the inverse of the block described for the encoder. The ATSC convolutional deinterleaver 334 is performed inversely with the ATSC convolutional interleaver and continues to track the normal / robust flag. Reed Solomon decoder 332 operates only on normal packets. The Reed Solomon decoder for robust data packets is bypassed. That is, parity bytes are stripped and only information bytes are sent (if a non-standard Reed Solomon encoder is used, another byte reordering per packet in the frame is performed before stripping the parity bytes). In the latter case, it provides an N / R signal to the VSB derandomizer that operates on both normal and robust bytes.

The output of the derandomizer is first sent to a normal / robust packet separator 336 which collects normal and robust data packets in separate buffers. For generic packets, MPEG sync is added (338) and transmitted as generic MPEG packets. For robust bytes, first the 3-byte header for all 187-byte packets is removed, resulting in an 184-byte packet. The next two 184-byte packets become one 184-byte packet according to the encoding described within the robust packet preprocessor. The resulting 184-byte packet is sent to the next robust postprocessor. The robust post-processor performs Reed Solomon 184 and 164 decoding. It also performs MPEG synchronous relocation if the Rovers payload type indicates the MPEG protocol.

Claims (28)

A method of transmitting second data via a communication system that encodes the first data by a first encoding method in response to receiving first data, the method comprising: Encoding the second data by a second encoding method to form encoded second data; Multiplexing the first data with the encoded second data to form multiplexed data; And transmitting the multiplexed data through the communication system. 2. The method of claim 1, wherein the first encoding method is rate 2/3 trellis encoding. 3. The method of claim 2, wherein the second encoding method is rate 1/2 trellis encoding. 4. The method of claim 3, wherein the communication system further comprises integral pre-coding of data prior to the first encoding method, Processing the second data by differentiating the second data to deactivate the integral pre-coding of the data when the encoded second data is transmitted through the communication system. How to send data. 5. The method of claim 4, further comprising selectively inverting or non-inverting the first data transmitted through the communication system to eliminate phase errors caused by differentiating the second data. Transmission method. 2. The system of claim 1, wherein the communication system further comprises MPEG packets having an MPEG packet length, Dividing the second data into second data packet lengths, each of the second data packet lengths being less than the MPEG packet length; Appending header bytes to each of the second data packet lengths, wherein each of the header bytes corresponds to a NULL packet header and the header bytes are encoded as the first data; Encoding each of the second data packet lengths by the second encoding method. The method of claim 1, Dividing the second data into a plurality of robust data packets; Calculating Reed Solomon parity bytes for each of the plurality of robust data packets; Transmitting each of the Reed Solomon parity bytes for each of the plurality of robust data packets as the first data; Transmitting each of the plurality of robust data packets as the second data. The method of claim 1, Dividing the second data into a plurality of data packets; Calculating Reed Solomon parity bytes for each of the plurality of data packets; Combining each of the Reed Solomon parity bytes with the plurality of data packets to form a robust data packet; And transmitting said robust data packet as said second data. An apparatus for transmitting second data via a communication system for encoding the first data in a first encoder in response to receiving first data, the apparatus comprising: A second encoder for forming encoded second data in response to receiving the second data; A multiplexer configured to form multiplexed data in response to receiving the encoded second data and the first data, And a transmitter is coupled to the multiplexer to transmit the multiplexed data via the communication system. 10. The apparatus of claim 9, wherein the first encoder is a speed 2/3 trellis encoder. 11. The apparatus of claim 10, wherein the second encoder is a rate 1/2 trellis encoder. 12. The apparatus of claim 11, wherein the communication system further comprises an integral pre-coder before the first encoder, And a differentiator coupled to the second data to deactivate the integral pre-coder of the data when the encoded second data is transmitted through the communication system. 13. The apparatus of claim 12, further comprising circuitry for selectively inverting or non-inverting the first data transmitted through the communication system. 10. The apparatus of claim 9, wherein the communication system further comprises MPEG packets having an MPEG packet length, Means for dividing the second data into second data packet lengths, each of the second data packet lengths being less than the MPEG packet length; Means for appending header bytes to each of the second data packet lengths, wherein each of the header bytes corresponds to a NULL packet header and the header bytes are encoded as the first data; Means for encoding each of said second data packet lengths by said second encoding method. The method of claim 9, Means for dividing the second data into a plurality of robust data packets; Means for calculating a Reed Solomon parity byte for each of the plurality of robust data packets; Means for transmitting each of the Reed Solomon parity bytes for each of the plurality of robust data packets as the first data; Means for transmitting each of the plurality of robust data packets as the second data. The method of claim 9, Means for dividing the second data into a plurality of data packets; Means for calculating Reed Solomon parity bytes for each of the plurality of data packets; Means for combining each of the Reed Solomon parity bytes with the plurality of data packets to form a robust data packet; And means for transmitting the robust data packet as the second data. A method of transmitting robust data through an 8VSB digital television communication system that transmits normal data as MPEG transport packets by a 2/3 trellis encoding method. Encoding the robust data by a half trellis encoding method to form encoded robust data; Multiplexing the encoded robust data with the MPEG transport packets to form multiplexed data; And transmitting the multiplexed data via the 8VSB digital television communication system. 18. The system of claim 17, wherein the 8VSB digital television communication system further comprises integral pre-coding of data, And when the encoded robust data is transmitted via the 8VSB digital television communication system, differentiate the robust data to deactivate integral pre-coding of the data. Transmission method. 19. The method of claim 18, further comprising selectively inverting or non-inverting the general data transmitted through the 8VSB digital television communication system to eliminate phase errors generated by differentiating the robust data. Robust data transmission method to perform. 18. The system of claim 17, wherein the 8VSB digital television communication system further comprises MPEG packets having an MPEG packet length, Dividing the robust data into robust data packet lengths, each of the robust data packet lengths being less than the MPEG packet length; And attaching header bytes to each of the robust data packet lengths, each of the header bytes corresponding to a NULL packet header, wherein the header bytes are encoded as the generic data. How to send data. The method of claim 17, Calculating Reed Solomon parity bytes for the robust data; And transmitting each of the Reed Solomon parity bytes for the robust data as the general data. The method of claim 21, Dividing the robust data into a plurality of data packets; Calculating Reed Solomon parity bytes for each of the plurality of data packets; Combining the Reed Solomon parity bytes with the encoded robust data. An 8VSB digital television communication system for transmitting normal data as MPEG transport packets by a 2/3 trellis encoding method, the apparatus for transmitting robust data through the 8VSB digital television communication system, A half trellis encoder for forming encoded robust data in response to receiving the robust data; And a multiplexer for forming multiplexed data in response to receiving the encoded robust data and the MPEG transport packets, And a transmitter is coupled to the multiplexer to transmit the multiplexed data via the 8VSB digital television communication system. 24. The system of claim 23, wherein the 8VSB digital television communication system further comprises an integrated pre-coder of data, And a differentiator coupled to the robust data to deactivate the integral pre-coder when the encoded robust data is transmitted via the 8VSB digital television communication system. 25. The circuit of claim 24, further comprising circuitry for selectively inverting or non-inverting the general data transmitted through the 8VSB digital television communication system to eliminate phase errors caused by differentiating the robust data packets. Robust data transmission device. 24. The system of claim 23, wherein the 8VSB digital television communication system further comprises MPEG packets having an MPEG packet length, Means for dividing the robust data into robust data packet lengths, each of the robust data packet lengths being less than the MPEG packet length; And means for appending header bytes to each of said robust data packet lengths, each of said header bytes corresponding to a NULL packet header, said header bytes being encoded as said general data. Data transmission device. The method of claim 23, wherein Means for calculating Reed Solomon parity bytes for the robust data; And means for transmitting each of the Reed Solomon parity bytes for the robust data as the generic data. The method of claim 27, Means for dividing the robust data into a plurality of data packets; Means for calculating Reed Solomon parity bytes for each of the plurality of data packets; And means for combining the Reed Solomon parity bytes with the encoded robust data.

Images