WO2011068495A1 - Data block identification in a mobile dtv system with diversity - Google Patents

Data block identification in a mobile dtv system with diversity Download PDF

Info

Publication number
WO2011068495A1
WO2011068495A1 PCT/US2009/006366 US2009006366W WO2011068495A1 WO 2011068495 A1 WO2011068495 A1 WO 2011068495A1 US 2009006366 W US2009006366 W US 2009006366W WO 2011068495 A1 WO2011068495 A1 WO 2011068495A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
fec
block
data block
data field
Prior art date
Application number
PCT/US2009/006366
Other languages
French (fr)
Inventor
Ivonete Markman
Aaron Reel Bouillet
Original Assignee
Thomson Licensing
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing filed Critical Thomson Licensing
Priority to PCT/US2009/006366 priority Critical patent/WO2011068495A1/en
Publication of WO2011068495A1 publication Critical patent/WO2011068495A1/en

Links

Classifications

    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2957Turbo codes and decoding
    • H03M13/296Particular turbo code structure
    • H03M13/2963Turbo-block codes, i.e. turbo codes based on block codes, e.g. turbo decoding of product codes
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/27Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes using interleaving techniques
    • H03M13/2703Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes using interleaving techniques the interleaver involving at least two directions
    • H03M13/2707Simple row-column interleaver, i.e. pure block interleaving
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/27Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes using interleaving techniques
    • H03M13/2732Convolutional interleaver; Interleavers using shift-registers or delay lines like, e.g. Ramsey type interleaver
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2957Turbo codes and decoding
    • H03M13/296Particular turbo code structure
    • H03M13/2972Serial concatenation using convolutional component codes
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/3707Adaptive decoding and hybrid decoding, e.g. decoding methods or techniques providing more than one decoding algorithm for one code
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/65Purpose and implementation aspects
    • H03M13/6577Representation or format of variables, register sizes or word-lengths and quantization
    • H03M13/658Scaling by multiplication or division
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0041Arrangements at the transmitter end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0075Transmission of coding parameters to receiver

Definitions

  • the present invention generally relates to digital television (DTV) systems and methods, and more particularly to mobile DTV systems and methods.
  • DTV digital television
  • FIG. 1 shows a simplified block diagram of a typical ATSC compliant DTV transmitter and receiver, emphasizing the FEC subsystem.
  • the FEC encoding subsystem consists of a Reed-Solomon (RS) encoder, followed by a byte interleaver, and a trellis encoder.
  • RS Reed-Solomon
  • the receiver side there is a corresponding trellis decoder, a byte de- interleaver and a RS decoder.
  • the ATSC DTV transmission scheme is not robust enough against Doppler shift and multipath radio interference, and is designed for highly directional fixed antennas, hindering the provision of expanded services to customers using mobile and handheld (M/H) devices.
  • M/H mobile and handheld
  • FEC coding may require decoding techniques such as iterative (turbo) decoding (see, e.g., C.
  • the FEC system may allow for transmission with time diversity as described in International Patent Applications WO 2008/144004 and 2009/064468.
  • the systems described therein attempt to provide backwards compatibility with the current DTV standard, no other known systems permit diversity within their coding structure.
  • a stream of data bursts with alternating groups of information blocks and parity blocks— each group of information blocks including a plurality of information blocks and each group of parity blocks including a plurality of parity blocks— is transmitted with forward error correction (FEC) and diversity.
  • FEC forward error correction
  • Each group of information and parity block is contained in one or more data fields of a data burst and may be fully encoded by all levels of FEC coding.
  • a data block identifier flag is placed in a reserved field of a data field synchronization segment of the data field to indicate the presence of a group of information or parity blocks in the data field.
  • the data field synchronization segment is not FEC encoded. Detection of the data block identifier flag allows a receiver to identify the presence of information or parity blocks prior to FEC decoding. As a result, FEC decoding at the receiver is improved with lower overall latency.
  • FIG. 1 is a block diagram of an illustrative digital television (DTV) transmitter and receiver system
  • FIG. 2A depicts an illustrative DTV data frame
  • FIG. 2B depicts the format of a Data Sync Segment within the DTV data frame of FIG. 2A;
  • FIG. 3 depicts an example of a DTV M/H system in accordance with the principles of the current arrangement
  • FIG. 5 depicts an example of a second FEC encoder
  • FIGs. 6 A and 6B depict the operation of an exemplary Packet Interleaver taking bytes from a fixed number of consecutive packets in a row-by-row order, and outputting the bytes column-by-column;
  • FIGs. 7 A and 7B depict the operation of an exemplary Packet Deinterleaver taking bytes from resulting block code codewords for the original group of packets in a column-by-column order, and outputting the bytes in a row-by-row order;
  • FIG. 8 depicts an example of a receiver implementation for a mobile DTV system used in the present arrangement
  • FIG. 9 depicts an example of a High Latency (HL) FEC decoder according to the present arrangement
  • FIG. 10 depicts an example of a Low Latency (LL) FEC decoder according to the present arrangement
  • FIG. 11 depicts an example of a HL FEC core according to the present arrangement
  • FIG. 12 A depicts an example of a mobile DTV transmitter supporting time diversity according to the present arrangement
  • FIG. 12B depicts two data streams combined in the transmitter of FIG. 12A to generate a time diversity data stream for transmission;
  • FIG. 13 A depicts an example of a receiver implementation for a mobile DTV system with time diversity used in the present arrangement
  • FIG. 13B depicts two data streams processed by a dual-path iterative FEC decoder in the receiver of FIG. 13 A
  • FIG. 14A depicts an HL FEC core supporting time diversity for use in the iterative FEC decoder of the receiver of FIG. 13 A
  • FIG. 14B depicts the operation of a stagger multiplexer in the HL FEC core of FIG. 14A;
  • FIG. 15 depicts a flowchart of the steps taken by the HL FEC to decode digital data according to an exemplary embodiment of the present arrangement.
  • FIG. 1 shows an example of a DTV system that incorporates FEC.
  • FEC in a system provides for error control for data transmissions. This is performed by sending redundant data, known as error correction codes, that allow the receiver to detect and correct errors without the need to ask the sender for additional data or resending of data.
  • Input digital data which may be considered any of video, audio, textual, or other information data, is encoded using a DTV standard and transmitted to a receiver which decodes the digital data.
  • FIG. 2A shows the format of an ATSC-DTV data frame as transmitted in an ATSC-DTV compliant system, such as that of FIG. 1.
  • Each data frame consists of two Data Fields, each containing 313 segments.
  • the first segment of each Data Field is a unique synchronization segment (Data Field Sync) shown in greater detail in FIG. 2B and further discussed below.
  • Data Field Sync Data Field Sync
  • Each of the remaining 312 segments of each Data Field referred to as data segments, carries the equivalent data of one 188-byte MPEG- compatible transport packet and its associated FEC overhead.
  • the 312 data segments are contained in the portions of the Data Fields of FIG. 2A labeled DATA+FEC. Note that while the 312 data segments of each Data Field contain FEC encoded data, the Data Field Sync segment is not FEC encoded and thus need not be FEC decoded at the receiver.
  • Each segment consists of 832 8-VSB symbols.
  • FIG. 2B which shows a Data Field Sync segment in greater detail
  • the first four 8-VSB symbols of each segment have values of +5, -5, -5, and +5.
  • This four-symbol segment sync signal also represents the sync byte of each 188- byte MPEG-compatible transport packet conveyed by each of the 312 data segments in each Data Field.
  • the remaining 828 symbols of each data segment carry data equivalent to the remaining 187 bytes of a transport packet and its associated FEC overhead.
  • each segment takes 77.3 to transmit, thereby taking 48.4 ms to transmit one ATSC-DTV data frame.
  • FIG. 2B shows a Data Field Sync segment in greater detail.
  • each Data Field Sync segment starts with a four-symbol segment sync followed by several pseudo random or pseudo noise (PN) sequences, a VSB mode field and a RESERVED field of 104 symbols.
  • PN pseudo random or pseudo noise
  • PRECODE pseudo random or pseudo noise
  • an exemplary embodiment of the invention makes advantageous use of all or part of the RESERVED field of the Data Field Sync segment to provide improved reception and a simplified receiver design.
  • FIG. 3 shows a simplified block diagram of an exemplary transmitter and receiver for an M/H DTV system, hereby called DTV-M/H, wherein the added layer of FEC encoding, exemplified by FEC Encoder 2, may comprise a packet block code, and FEC Encoder 1 is compatible with the ATSC FEC encoder shown in FIG. 1.
  • the Iterative FEC Decoder performs turbo decoding of the various FEC encoders.
  • the Iterative FEC decoder in question may comprise MAP decoding of the ATSC trellis decoder and the added FEC codes within FEC Encoder 2 which will iteratively interact, resulting in each decoder sending extrinsic information to the other.
  • the Iterative FEC Decoder will perform a number of iterations M deemed necessary to achieve a desired system performance.
  • the block code is such that for each K packets of data, having 187 information bytes (assuming MPEG packets without the sync byte, 0x47 or 47 Hex, as in the ATSC standard), the block code adds N- K parity packets.
  • This block code may be a Serial Concatenated Block Code (SCBC) over a Galois Field GF(256) similar to that described in International Patent Application WO 2008/144004 mentioned above, wherein each column in FIG. 3 would be a separate code word of N bytes associated with the first K information bytes.
  • SCBC Serial Concatenated Block Code
  • FEC block encoder 514 may be preceded by a packet interleaver 512 and followed by a packet deinterleaver 516.
  • the operation of packet interleaver 512 and packet deinterleaver 516 are set forth more specifically hereinafter with reference to FIGs. 6A and B, and 7A and B, respectively.
  • Each source packet is an MPEG transport stream packet with the 0x47 sync byte removed, as in the A/53 ATSC DTV standard. As a result each packet has a length of 187 bytes. The number of packets in each code frame is the same as the number of source symbols required for the GF(256) Serial Concatenated Block Code.
  • the Packet Interleaver is known in the art as a (K, 187) matrix interleaver.
  • the Packet Deinterleaver is specified as a (N, 187) matrix deinterleaver
  • a data burst comprising three Data Fields, FO, Fl and F2, is repetitively transmitted, each corresponding to 1.5 frames of the legacy ATSC- DTV standard, such as shown in FIG. 2A.
  • a DTV-M/H receiver When receiving a data burst such as set forth in Table 1, a DTV-M/H receiver will discard the Legacy ATSC data segments in Data Fields F0-F2 and process the 156 DTV-M/H Data Segments in Data Field F0.
  • the 156 DTV-M/H Data Segments may contain, for example, encoded video data and/or preamble training data, also called a priori tracking (APT) data.
  • the preamble training data is to be utilized by the DTV-M/H receiver in order to enhance performance.
  • This preamble training data is fully encoded by all levels of legacy ATSC FEC coding in the system (FEC encoder 1), as well as being interleaved and randomized.
  • the number and location of DTV-M/H Data Segments can be different in different embodiments.
  • FIG. 8 shows a general block diagram of an exemplary DTV-M/H receiver 810 used in the present arrangement.
  • the receiver 810 is generally composed of a demodulator 812, equalizer 814, FEC decoder 818 and transport function block 824, which includes video decoding.
  • FEC decoder 818 has two levels: High Latency (HL) 820, which has N iterations or cores and feeds the transport block, and Low Latency (LL) 822 with M ⁇ N iterations or cores, which feeds the equalizer to increase its performance.
  • HL High Latency
  • LL Low Latency
  • FIG. 9 shows a more detailed block diagram of HL FEC 820.
  • HL FEC 820 has a plurality of HL Cores represented by HL Corel 910, HL Core2 912, and HL CoreN 914, and as a last block, a legacy ATSC FEC block 916.
  • Legacy ATSC FEC Block 916 includes a combination of the legacy FEC functions associated with the legacy ATSC decoder in FIG. 1, including particularly, an RS decoder, derandomizer and data interface to the transport block.
  • FIG. 10 shows a more detailed diagram of LL FEC 822.
  • LL FEC 822 has a plurality of LL Cores represented by LL Corel 1010, LL Core2 1012, and LL CoreM 1014.
  • LL FEC 822 also has as a last block, a trellis or MAP decoder 1016, since it is feeding 8-VSB symbols to equalizer 814 of FIG. 8.
  • the main difference between the HL and LL cores is the latency of the core blocks. Because LL FEC 822 feeds equalizer 814 of FIG. 8, its functionality must be designed for minimum latency, and therefore, it may not be as robust as HL FEC 820 in performance.
  • FIG. 11 shows a block diagram of an HL FEC Corel-N such as HL Core 910 of FIG. 9.
  • the input to each core consists of two streams: the first stream is the originally received stream (after demodulation and equalization), which is delayed and unaltered within each core to match the processing delay of the core and sent to the following core; and the second stream is a stream of extrinsic information associated with the received stream, as processed by the previous core.
  • a noise estimator 918, metric generator 920 and MAP decoder 922 may be included in the HL FEC core, all of which are known in the art.
  • Noise estimator 918 estimates the noise power in a received input stream to an HL FEC core.
  • Metric generator 920 compares the symbols in the received input stream against the optimal 8-VSB values and calculates and stores the metrics needed by MAP decoder 922, for the specific noise power. In addition, metric generator 920 calculates, stores and passes to MAP decoder 922 extrinsic information from the previous FEC core, also called a priori metrics. MAP decoder 922 decodes the ATSC trellis code with the metrics and the a priori metrics received from metric generator 920 and produces dual- bits. [0040] Symbol to byte converter (S2B) 924 groups dual-bit outputs of MAP decoder 922 associated with each 8-VSB symbol in bytes (4 dual-bits per byte).
  • S2B Symbol to byte converter
  • the output of MAP decoder 922 is a soft decision version of a dual-bit, instead of 2 bits. For example, each dual-bit could be represented by 20 bits and a soft byte would then be represented by 80 bits.
  • S2B 924 also converts the stream from symbol based to byte based.
  • Convolutional deinterleaver 928 is connected between S2B 924 and derandomizer 930.
  • Convolutional deinterleaver 928 and derandomizer 930 have the same functionality as in the legacy ATSC standard as well as having the additional ability to handle soft bytes of more than 8 bits.
  • Convolutional deinterleaver 928 rearranges the received data from a previously interleaved sequence.
  • Derandomizer 930 derandomizes the received data to prepare the data for processing by ScaleO 936.
  • ScaleO 936 scales the soft bytes of the data stream received from derandomizer 930 by a chosen factor. This factor is microprocessor controlled. The scaling factor can be between 0.5 and 1.0, varying for each core. Properly chosen values optimize performance of the HL FEC.
  • Packet demultiplexer 940 discards legacy ATSC data and only passes DTV- M/H data to the remaining blocks.
  • Packet interleaver 942 receives the signals from packet demultiplexer 940 and performs block interleaving operations associated with the GF(256) SCBC block code.
  • SCBC decoder 946 receives data from packet interleaver 942 and performs the block decoding operation for the GF (256) SCBC blocks, as discussed previously. SCBC decoder 946 handles soft bytes, and is also a soft decision block decoder.
  • SCBC-to-SCBC interface 948 connects two SCBC decoders from two adjacent cores in order to pass extrinsic information and control signals from one FEC core to the next.
  • SRAM control 950 interfaces the packet interleaver 942, packet deinterleaver 944 and SCBC decoder 946 to an SRAM needed to perform their respective functionalities.
  • Packet deinterleaver 944 receives data from SCBC decoder 946 and performs the block deinterleaving operations associated with the GF(256) SCBC block code.
  • Packet multiplexer 952 receives data from packet deinterleaver 944 and recreates a full stream with both legacy and mobile data by obtaining the mobile data from the extrinsic information received from SCBC decoder block 946 (through packet deinterleaver 944) and zeroing the legacy data, since it is not of interest to the mobile DTV decoder.
  • the SCBC extrinsic information is used to enhance the performance of the MAP decoder of the subsequent core or iteration.
  • Scale 1 938 scales the soft bytes of the data stream received from packet multiplexer 952 by a chosen factor. This factor is microprocessor controlled. The scaling factor can be between 0.5 and 1.0, varying for each core. Properly chosen values optimize performance of the HL FEC.
  • Rerandomizer 934 is connected between Scale 1 938 and convolutional interleaver 932.
  • Rerandomizer 934 has the same functionality as in the legacy ATSC standard as well as the additional ability to handle soft bytes of more than 8 bits.
  • Rerandomizer 934 randomizes the received data.
  • Convolutional interleaver 932 rearranges the received data into a sequence that is less prone to long sequences of errors.
  • Byte-to-symbol converter (B2S) block 926 performs the inverse functionality of S2B block 924. It separates a soft byte into soft dual-bits and converts the data from byte based to symbol based.
  • B2S to metric generator interface 956 obtains extrinsic information from B2S 926 and the delayed received input signals (data and sync) from the core input, and synchronizes these two sets of data with minimum latency and loss of data, outputting the two sets of data to the next core.
  • Equalizer to metric generator delay 954 delays the originally received data stream, field and segment sync, as well as other synchronization signals to match the overall latency of the current core blocks. In addition it passes a symbol enable from the input to the output of the core without delay.
  • the LL FEC core is a subset of the HL FEC core, where some of the blocks of the HL FEC core are replaced by a simpler functionality in order to decrease latency. As a result, some portions of data are lost but the remaining extrinsic information must still be synchronized with the core input data and fed to the next core.
  • the Metric generator and MAP decoder of the LL FEC core have a reduced latency, and therefore, lesser performance than in the HL FEC core.
  • the convolutional deinterleaver, derandomizer, convolutional interleaver, (re)randomizer, packet demultiplexer, packet interleaver, packet deinterleaver, and packet multiplexer are not present in the LL FEC core and instead are replaced by different, simplified components that perform the operations of (de)randomizing and (re)randomizing as well as extracting the mobile data of interest, which is a subset of the entire mobile data.
  • the SCBC decoder of the LL FEC core has a different code rate than the HL FEC code rate for the purpose of decreasing the latency of the core.
  • the Equalizer to metric generator delay block of the LL FEC core has a smaller latency than in the HL FEC core.
  • an exemplary mobile DTV system is flexible enough for transmission with time diversity.
  • the main flexibility comes from the structure of the block code (e.g., GF(256)) and the organization of segments (or packets) of data into separate blocks of information and parity packets.
  • An information block contains information packets and possibly some parity packets, whereas a parity block contains parity packets but no information packets.
  • a parity block may be such that the information packets can be derived from them, that is, a parity block contains a linear combination of all the information packets.
  • These information or parity blocks can then be delayed with respect to each other before transmission. In an exemplary system, the delay can be within a range of 8 to 10 seconds to provide robust time diversity.
  • the present arrangement provides a time diversity scheme associated with the data and parity blocks of packets of the GF (256) SCBC encoder.
  • Each codeword of 52 packets is split into two blocks, A and B, of 26 packets each.
  • the A block contains 12 information packets and 14 parity packets, and is hereby called information block.
  • the B block contains only parity packets and is hereby called parity block.
  • information (A) and parity (B) blocks in FIG. 4 are 26 packets each and serially transmitted, where A and B jointly compose a 52 packet block out of the SCBC encoder or the packet deinterleaver.
  • the code rate R is exemplary and may be defined as a different value, which would also result in different sized A and B blocks.
  • FIG. 12A shows an exemplary embodiment of a transmitter 1200 for use in a mobile DTV system supporting time diversity.
  • the original stream without diversity out of the SCBC encoder or the packet deinterleaver and into the input to the transmitter 1200 can be represented as Data Stream 1:
  • the A and B blocks are first grouped in accordance with the size of the portion of the Data Field in the data burst of TABLE 1 containing the DTV-M/H Data segments.
  • this portion which is in Data Field F0, contains 156 data segments, or packets. This is the equivalent of six A or six B blocks of 26 packets each.
  • Block coder 1212 reorganizes Data Stream 1, composed of alternating A and B blocks, into alternating groups of six, as represented by Data Stream 2: I A(0) I A(l) I A(2) I A(3)
  • I A(8) I A(9) I A(10) I A(l l)
  • Block coder 1212 outputs the AA and BB blocks in Data Stream 3 separately and provides the BB blocks to delay buffer 1214 which delays the BB blocks relative to the AA blocks, thereby creating Data Streams 4A and 4B shown in FIGs. 12A and B.
  • Delay buffer 1214 introduces a delay of L x 26 packets, providing an appropriate degree of time diversity (e.g., 8-10 seconds) for the broadcast medium.
  • Data Streams 4A and 4B are then combined at physical layer combiner 1216 by alternately taking a block from each stream to create time diversity Data Stream 5 as follows: I AA(0) I BB(-L) I AA(1)
  • Data Stream 5 at the output of physical layer combiner 1216 is provided to transmitter block 1250 which has the ability to transfer the time diversity stream of Data Stream 5 to a receiver.
  • Transmitter block 1250 can be implemented conventionally as a legacy ATSC transmitter, such as shown in FIG. 1.
  • Data Stream 5 is transmitted from transmitter 1200 in a sequence of data bursts in which successive data bursts (in particular, the 156 DTV-M/H Data segments in Data Field F0 thereof) contain either an AA block or a BB block, in accordance with the alternating pattern of AA and BB blocks represented by Data Stream 5.
  • successive data bursts in particular, the 156 DTV-M/H Data segments in Data Field F0 thereof
  • the receiver will need to determine whether a data burst contains an A A block or a BB block.
  • a scheme is provided to facilitate this determination, thereby simplifying receiver implementation and improving receiver performance.
  • a subset or the entirety of the RESERVED field (FIG. 2B) of the Data Field Sync segment of one or more Data Fields F0-F2 of the DTV-M/H data burst of TABLE 1 contains an indicator to identify the presence or absence of an AA or a BB block in the Data Field.
  • the indicator is referred to herein as a data block identifier flag.
  • This flag may be a particular pattern, data sequence, or a PN sequence, which preferably can be easily regenerated by a receiver field sync detector. If a PN sequence is used, it could be a portion of the PN511 or the PN63 sequences already used in the Data Field Sync segment (FIG.
  • the DTV-M/H Data Segments signal the beginning of a burst of mobile data to the receiver, the use of such a flag in the Data Field Sync segment of Data Field F0 allows a receiver to identify the mobile data burst and to determine whether it contains an AA block or a BB block. The receiver can then process the data burst and its contents accordingly.
  • the aforementioned identifier flag is placed in the Data Field Sync segment of at least one of Data Fields F0-F2, and preferably at least the Data Field Sync segment of Data Field F0.
  • the data block identifier flag may have a first value to indicate the presence of an AA block, a second value to indicate the presence of a BB block and a third value to indicate the absence of an A A or a BB block.
  • the data block identifier flag can take on one of two values, which may be complementary (e.g., logical inverses of each other).
  • the data block identifier flag takes on the first value and is placed in the Data Field Sync segment of Data Field F0.
  • the second (complementary) value is placed in the Data Field Sync segments of Data Fields Fl and F2.
  • the data block identifier flag takes on the second (complementary) value and is placed in the Data Field Sync segment of Data Field F0.
  • the first value is placed in the Data Field Sync segments of Data Fields Fl and F2.
  • the data block identifier flag could be placed in Data Field Fl, and its logical inverse in Data Fields F0 and F2. In this case, the data block identifier flag would identify Data Field Fl, with the AA or BB block being in the previous Data Field F0. Likewise, the data block identifier flag could be placed in Data Field F2 and its inverse in Data Fields F0 and Fl. In this case, the flag would identify Data Field F2, and the Data Field containing the AA or BB block, F0, would be the subsequent field.
  • AA or BB blocks for a data burst may be contained in one or more locations other than that shown in TABLE 1, including other Data Fields of the data burst.
  • a data block identifier flag may be placed in the Data Field Sync segment of only one Data Field of the data burst or in the Data Field Sync segment of each Data Field containing an AA or BB data block.
  • the placement of AA and BB data blocks within the same data burst or within the same Data Field is not precluded by the present arrangement.
  • AA and BB data blocks can be arranged in any of a plurality of patterns, with each pattern having a corresponding data block identifier flag value.
  • Data Field F0 may contain: 1) two AA blocks, 2) two BB blocks, 3) one AA block and one BB block, or 4) one BB block and one AA block.
  • the data block identifier flag could take on one of four values (1-4) to indicate each of the four patterns.
  • Transmitter 1200 includes a flag generator 1260, which in accordance with an indication from block coder 1212, generates and inserts a data block identifier flag into the RESERVED field of the Data Field Sync segment of one or more Data Fields in each data burst containing an AA or a BB block.
  • flag generator 1260 will generate and insert the aforementioned data block identifier flag in the RESERVED field of the Data Field Sync segment of Data Field F0 when associated with an AA data block and its logical inverse in the RESERVED field of the DATA Field Sync segment of Data Field F0 when associated with a BB data block.
  • Flag generator 1260 may also generate and insert logical inverses of said flag in the RESERVED field of the Data Field Sync segments of Data Fields Fl and F2.
  • FIG. 13A shows an exemplary receiver 1300 for the present arrangement.
  • delay buffer 1316 creates two versions of the transmitted stream, the first of which represents a delayed version of Data Stream 5, and the second of which represents the original stream, Data Stream 5. These two versions are represented by Data Streams 6d and 6, respectively, as shown in FIG. 13B, where Delay Buffer 1316 has a length of (2xL) x 26 packets.
  • FEC decoding block 1318 comprising High Latency (HL) FEC decoder 1320 and Low Latency (LL) FEC decoder 1322.
  • Receiver 1300 of FIG. 13 A also includes a field sync detector 1350 and a flag detector 1360.
  • Field sync detector 1350 looks for the presence of Data Field Sync segments (FIG. 2B) in the data stream at the output of demodulator 1312 or equalizer 1314 using correlation or any other suitable method.
  • Flag detector 1360 receives an indication from field sync detector 1350 of the presence of a Data Field Sync segment, thereby alerting flag detector 1360 to search for the possible presence of a data block identifier flag in the RESERVED field of the Data Field Sync segment.
  • Flag detector 1360 looks for the presence of a data block identifier flag in the received data stream at the output of demodulator 1312 or equalizer 1314. Using correlation techniques or the like, flag detector 1360 monitors the demodulated and/or equalized received data stream for a sequence of symbols matching one of the possible values of the data block identifier flag. If such a sequence of symbols is detected, flag detector 1360 provides the block identification information (e.g., AA, BB or neither) corresponding to the detected flag value to FEC decoder 1318 and equalizer 1314, accordingly.
  • block identification information e.g., AA, BB or neither
  • Flag Detector 1360 can be implemented to detect the data block identifier flag in the received data stream without field sync detector 1350.
  • a field sync detector, such as 1350 will typically be included in any receiver designed to receive data bursts with Data Field Sync segments, such as shown in FIG. 2B.
  • DTV-M/H data is FEC encoded
  • a conventional receiver would need to iteratively FEC decode the received data stream by multiple iterations before it can reliably detect whether a Data Field contains an AA block (or a BB block).
  • the exemplary receiver 1300 can identify the presence of an AA (or a BB) block rate prior to FEC decoding.
  • the indication that a data burst contains an AA (or BB block) can thus be provided as quickly as possible to equalizer 1314 and FEC decoder 1318 which need to identify the presence of such blocks as quickly as possible.
  • FIG. 14A is a block diagram of an HL FEC core for use in HL FEC decoder 1320.
  • LL FEC decoder 1322 comprises multiple LL FEC cores. Because the design of an LL FEC core can be a subset of the design of an HL FEC core, the description of the HL FEC core of FIG. 14 can also apply to an LL FEC core.
  • the HL FEC core has two separate FEC encoded inputs, PathO 1412 and Pathl 1414.
  • PathO 1412 and Pathl 1414 In the receiver 1300 of FIG. 13A, delayed data stream 6d from Delay Buffer 1316 is processed in SubcoreO via PathO while undelayed stream 6 is processed by Subcorel via Pathl.
  • two separate a priori output streams PathO 1416 and Pathl 1418 are delivered from one FEC core to the next, as part of the iterative FEC decoding process.
  • FIG. 14A also includes decoding block 1428 which contains similar blocks to those discussed with respect to FIG. 11.
  • Data Streams 6d and 6 are fed into inputs 1412 and 1414, respectively.
  • the streams are then processed by SubcoreO 1420 and Subcorel 1422, respectively, reaching packet demultiplexer 940 at the end of each subcore.
  • Stagger multiplexer 1430 receives Data Streams 6d and 6, as processed by subcores 1420 and 1422, and, as shown in FIG. 14B, creates one stream 7A of alternating AA blocks and zeroes and another stream 7B of alternating BB blocks and zeroes.
  • stagger multiplexer 1430 uses the data block detection indication from flag detector 1360 to generate streams 7A and 7B by extracting corresponding AA and BB blocks from Data Streams 6d and 6 and zeroing those blocks in Data Streams 6d and 6 which together do not form meaningful A&B SCBC codewords.
  • AA(0)&BB(0) form a meaningful block of SCBC codewords, but AA(L)&BB(-L) or BB(-L)&AA(L+1) do not.
  • stagger multiplexer 1430 may also deconstruct the grouping of six A blocks and six B blocks from Data Streams 7A and 7B in order to regenerate the stream represented by Data Stream 8: I A(0) I B(0) I A(l) I B(l)
  • stagger demultiplexer block 1432 receives Data Stream 8, and separates the A and B blocks of Data Stream 8. The blocks are regrouped according to Data Stream 2 and used to generate Data Streams 7A and 7B in order to deliver the streams back to SubcoreO 1420 and Subcorel 1422.
  • a and B blocks dictates that the passing of extrinsic information from one FEC core to the next occurs as a continuous stream without interruption at the MAP decoder which results in a 0.8dB gain in Additive White Gaussian Noise (AWGN) performance over other implementations in which A and B blocks are not grouped.
  • AWGN Additive White Gaussian Noise
  • FIG. 15 depicts a flowchart detailing the steps taken by the present arrangement to decode digital data.
  • a demodulator receives and demodulates a digital data stream including information and parity blocks.
  • an equalizer receives the demodulated digital data stream and compensates for distortions.
  • the Flag Detector (1360, FIG. 13 A) detects the presence of a data block identifier flag in the RESERVED field of a Data Field Sync segment of the incoming data burst.
  • the Flag Detector provides the appropriate indication (e.g., AA, BB or neither) to the equalizer and the FEC decoder.
  • a delay buffer generates a first stream of digital data representing a delayed version of the compensated digital data stream and a second stream of digital data representing the compensated digital data stream.
  • the first and second streams of digital data are received and processed by a high latency FEC decoder comprising multiple cores.
  • each core receives the first and second streams of digital data appropriately delayed by the previous core to match its processing delay plus a third and a fourth stream of digital data corresponding to extrinsic information from the previous core.
  • the first and third streams feed SubcoreO and the second and fourth streams feed Subcorel of each core.
  • Each core generates a third and fourth output stream of digital data of extrinsic information.
  • each core appropriately delays the first and second input data stream and outputs it to the following core as a first and a second output stream.
  • the last core sends its decoded output stream (from the output of HL CoreN 914, FIG. 9) to a Legacy ATSC FEC unit (916) which in turn outputs an error decoded MPEG stream to the transport unit (824, FIG. 8).
  • the transport unit (824) delivers video/audio streams to a DTV display.
  • the time diversity scheme described above may be extended to include frequency diversity if, for example, the A blocks are transmitted in one frequency and the B blocks in another frequency. At the receiver, those two frequencies would be demodulated and the streams regrouped into Data Stream 5 prior to FEC decoding.

Abstract

A stream of data bursts with alternating groups of information blocks and parity blocks-each group of information blocks including a plurality of information blocks and each group of parity blocks including a plurality of parity blocks-is transmitted with forward error correction (FEC) and diversity. Each group of information and parity blocks is contained in one or more data fields of a data burst and may be fully FEC encoded. A data block identifier flag placed in a data field synchronization segment of the data field indicates the presence of a group of information or parity blocks in the data field. Preferably, the data field synchronization segment is not FEC encoded. Detection of the data block identifier flag allows a receiver to identify the presence of information or parity blocks prior to FEC decoding. As a result, FEC decoding at the receiver is improved with lower overall latency.

Description

DATA BLOCK IDENTIFICATION IN A MOBILE DTV
SYSTEM WITH DIVERSITY
Field of Invention
[0001] The present invention generally relates to digital television (DTV) systems and methods, and more particularly to mobile DTV systems and methods.
Background
[0002] The Advanced Television Systems Committee (ATSC) standard for Digital Television (DTV) in the United States requires an 8-VSB transmission system which includes Forward Error Correction (FEC) as a means of improving system performance. (United States Advanced Television Systems Committee, "ATSC Digital Television Standard", (document A53.doc), September 16, 1995.) FIG. 1 shows a simplified block diagram of a typical ATSC compliant DTV transmitter and receiver, emphasizing the FEC subsystem. As shown in FIG. 1, on the transmitter side, the FEC encoding subsystem consists of a Reed-Solomon (RS) encoder, followed by a byte interleaver, and a trellis encoder. On the receiver side, there is a corresponding trellis decoder, a byte de- interleaver and a RS decoder.
[0003] The ATSC DTV transmission scheme, however, is not robust enough against Doppler shift and multipath radio interference, and is designed for highly directional fixed antennas, hindering the provision of expanded services to customers using mobile and handheld (M/H) devices. In an attempt to address these issues and to create a more robust and flexible system, it has been proposed, among other things, to add a new layer of FEC coding and more powerful decoding algorithms to decrease the Threshold of Visibility (TOV). The added layer of FEC coding may require decoding techniques such as iterative (turbo) decoding (see, e.g., C. Berrou et al., "Near Shannon Limit Error - Correcting Coding and Decoding: Turbo-Codes (1)", Proceedings of the IEEE International Conference on Communications - ICC'93, May 23-26, 1993, Geneva, Switzerland, pp. 1064-1070; and M. R. Soleymani et al., "Turbo Coding for Satellite and Wireless Communications", luwer Academic Publishers, USA, 2002) and trellis decoding algorithms like the MAP decoder (see, e.g., L. R. Bahl et al., "Optimal Decoding of Linear Codes for Minimizing Symbol Error Rate", IEEE Transactions on Information Theory, Vol. ΓΤ-20, No. 2, March 1974, pp. 284-287.)
[0004] In addition, the FEC system may allow for transmission with time diversity as described in International Patent Applications WO 2008/144004 and 2009/064468. Although the systems described therein attempt to provide backwards compatibility with the current DTV standard, no other known systems permit diversity within their coding structure.
Summary
[0005] In an exemplary embodiment in accordance with the principles of the invention, a stream of data bursts with alternating groups of information blocks and parity blocks— each group of information blocks including a plurality of information blocks and each group of parity blocks including a plurality of parity blocks— is transmitted with forward error correction (FEC) and diversity. Each group of information and parity block is contained in one or more data fields of a data burst and may be fully encoded by all levels of FEC coding. At the transmitter, a data block identifier flag is placed in a reserved field of a data field synchronization segment of the data field to indicate the presence of a group of information or parity blocks in the data field. Preferably, the data field synchronization segment is not FEC encoded. Detection of the data block identifier flag allows a receiver to identify the presence of information or parity blocks prior to FEC decoding. As a result, FEC decoding at the receiver is improved with lower overall latency.
[0006] In view of the above, and as will be apparent from the detailed description, other embodiments and features are also possible and fall within the principles of the invention.
Brief Description of the Figures
[0007] Some embodiments of apparatus and/or methods in accordance with embodiments of the present invention are now described, by way of example only, and with reference to the accompanying figures in which: [0008] FIG. 1 is a block diagram of an illustrative digital television (DTV) transmitter and receiver system;
[0009] FIG. 2A depicts an illustrative DTV data frame, and FIG. 2B depicts the format of a Data Sync Segment within the DTV data frame of FIG. 2A;
[0010] FIG. 3 depicts an example of a DTV M/H system in accordance with the principles of the current arrangement;
[0011] FIG. 4 depicts an example packet structure of a packet block code of code rate R = K/N in accordance with the principles of the current arrangement;
[0012] FIG. 5 depicts an example of a second FEC encoder;
[0013] FIGs. 6 A and 6B depict the operation of an exemplary Packet Interleaver taking bytes from a fixed number of consecutive packets in a row-by-row order, and outputting the bytes column-by-column;
[0014] FIGs. 7 A and 7B depict the operation of an exemplary Packet Deinterleaver taking bytes from resulting block code codewords for the original group of packets in a column-by-column order, and outputting the bytes in a row-by-row order;
[0015] FIG. 8 depicts an example of a receiver implementation for a mobile DTV system used in the present arrangement;
[0016] FIG. 9 depicts an example of a High Latency (HL) FEC decoder according to the present arrangement;
[0017] FIG. 10 depicts an example of a Low Latency (LL) FEC decoder according to the present arrangement;
[0018] FIG. 11 depicts an example of a HL FEC core according to the present arrangement;
[0019] FIG. 12 A depicts an example of a mobile DTV transmitter supporting time diversity according to the present arrangement, and FIG. 12B depicts two data streams combined in the transmitter of FIG. 12A to generate a time diversity data stream for transmission;
[0020] FIG. 13 A depicts an example of a receiver implementation for a mobile DTV system with time diversity used in the present arrangement, and FIG. 13B depicts two data streams processed by a dual-path iterative FEC decoder in the receiver of FIG. 13 A; [0021] FIG. 14A depicts an HL FEC core supporting time diversity for use in the iterative FEC decoder of the receiver of FIG. 13 A, and FIG. 14B depicts the operation of a stagger multiplexer in the HL FEC core of FIG. 14A; and
[0022] FIG. 15 depicts a flowchart of the steps taken by the HL FEC to decode digital data according to an exemplary embodiment of the present arrangement.
Detailed Description
[0023] FIG. 1 shows an example of a DTV system that incorporates FEC. FEC in a system provides for error control for data transmissions. This is performed by sending redundant data, known as error correction codes, that allow the receiver to detect and correct errors without the need to ask the sender for additional data or resending of data. Input digital data, which may be considered any of video, audio, textual, or other information data, is encoded using a DTV standard and transmitted to a receiver which decodes the digital data.
[0024] FIG. 2A shows the format of an ATSC-DTV data frame as transmitted in an ATSC-DTV compliant system, such as that of FIG. 1. Each data frame consists of two Data Fields, each containing 313 segments. The first segment of each Data Field is a unique synchronization segment (Data Field Sync) shown in greater detail in FIG. 2B and further discussed below. Each of the remaining 312 segments of each Data Field, referred to as data segments, carries the equivalent data of one 188-byte MPEG- compatible transport packet and its associated FEC overhead. The 312 data segments are contained in the portions of the Data Fields of FIG. 2A labeled DATA+FEC. Note that while the 312 data segments of each Data Field contain FEC encoded data, the Data Field Sync segment is not FEC encoded and thus need not be FEC decoded at the receiver.
[0025] Each segment consists of 832 8-VSB symbols. The first four symbols of each segment, including each Data Field Sync segment, form a binary pattern and provide segment synchronization. As shown in FIG. 2B, which shows a Data Field Sync segment in greater detail, the first four 8-VSB symbols of each segment have values of +5, -5, -5, and +5. This four-symbol segment sync signal also represents the sync byte of each 188- byte MPEG-compatible transport packet conveyed by each of the 312 data segments in each Data Field. The remaining 828 symbols of each data segment carry data equivalent to the remaining 187 bytes of a transport packet and its associated FEC overhead.
[0026] As shown in FIG. 2A, each segment takes 77.3 to transmit, thereby taking 48.4 ms to transmit one ATSC-DTV data frame.
[0027] As mentioned, FIG. 2B shows a Data Field Sync segment in greater detail. As shown in FIG. 2B, each Data Field Sync segment starts with a four-symbol segment sync followed by several pseudo random or pseudo noise (PN) sequences, a VSB mode field and a RESERVED field of 104 symbols. (Note that the last 12 symbols of the RESERVED field, labeled PRECODE, are used in trellis coded terrestrial 8-VSB to replicate the last 12 symbols of the previous segment.) As described in greater detail below, an exemplary embodiment of the invention makes advantageous use of all or part of the RESERVED field of the Data Field Sync segment to provide improved reception and a simplified receiver design.
[0028] FIG. 3 shows a simplified block diagram of an exemplary transmitter and receiver for an M/H DTV system, hereby called DTV-M/H, wherein the added layer of FEC encoding, exemplified by FEC Encoder 2, may comprise a packet block code, and FEC Encoder 1 is compatible with the ATSC FEC encoder shown in FIG. 1. At the receiver, the Iterative FEC Decoder performs turbo decoding of the various FEC encoders. The Iterative FEC decoder in question may comprise MAP decoding of the ATSC trellis decoder and the added FEC codes within FEC Encoder 2 which will iteratively interact, resulting in each decoder sending extrinsic information to the other. In addition, the Iterative FEC Decoder will perform a number of iterations M deemed necessary to achieve a desired system performance.
[0029] FIG. 4 shows a packet structure of a Packet Block Code having a rate R = K/N in accordance with the principles of the current arrangement. The block code is such that for each K packets of data, having 187 information bytes (assuming MPEG packets without the sync byte, 0x47 or 47 Hex, as in the ATSC standard), the block code adds N- K parity packets. This block code may be a Serial Concatenated Block Code (SCBC) over a Galois Field GF(256) similar to that described in International Patent Application WO 2008/144004 mentioned above, wherein each column in FIG. 3 would be a separate code word of N bytes associated with the first K information bytes. [0030] FIG. 5 shows an exemplary embodiment of a FEC Encoder according to the present arrangement. FEC block encoder 514 may be preceded by a packet interleaver 512 and followed by a packet deinterleaver 516. The operation of packet interleaver 512 and packet deinterleaver 516 are set forth more specifically hereinafter with reference to FIGs. 6A and B, and 7A and B, respectively.
[0031] The Packet Interleaver 512 may take bytes from a fixed number of consecutive packets in a row-by-row order as shown in FIG. 6A, and outputs the bytes column-by-column, as shown in FIG. 6B, for the case of R = 12/26. In this manner, all first bytes of the packets will be grouped together, all second bytes of the packets will be grouped together, and so on to the last bytes of the packets. Each source packet is an MPEG transport stream packet with the 0x47 sync byte removed, as in the A/53 ATSC DTV standard. As a result each packet has a length of 187 bytes. The number of packets in each code frame is the same as the number of source symbols required for the GF(256) Serial Concatenated Block Code. The Packet Interleaver is known in the art as a (K, 187) matrix interleaver.
[0032] The Packet Deinterleaver 516 may take bytes from the resulting SCBC codewords for the original group of packets in a column-by-column order as shown in Fig. 7 A. The bytes are then output row-by-row, as shown in Fig. 7B, for the case of R= 12/26. In this manner, the original packets are reconstituted and new packets are created from the parity bytes of the SCBC codewords. Each packet corresponds to a common GF(256) symbol location in all created SCBC codewords. The Packet Deinterleaver is specified as a (N, 187) matrix deinterleaver
[0033] An example of a burst repetitive data structure for transmission of DTV-M/H data is given in TABLE 1.
TABLE 1
Figure imgf000008_0001
[0034] As shown in TABLE 1, a data burst comprising three Data Fields, FO, Fl and F2, is repetitively transmitted, each corresponding to 1.5 frames of the legacy ATSC- DTV standard, such as shown in FIG. 2A.
[0035] When receiving a data burst such as set forth in Table 1, a DTV-M/H receiver will discard the Legacy ATSC data segments in Data Fields F0-F2 and process the 156 DTV-M/H Data Segments in Data Field F0. The 156 DTV-M/H Data Segments may contain, for example, encoded video data and/or preamble training data, also called a priori tracking (APT) data. The preamble training data is to be utilized by the DTV-M/H receiver in order to enhance performance. This preamble training data, however, is fully encoded by all levels of legacy ATSC FEC coding in the system (FEC encoder 1), as well as being interleaved and randomized. As can be appreciated, the number and location of DTV-M/H Data Segments can be different in different embodiments.
[0036] FIG. 8 shows a general block diagram of an exemplary DTV-M/H receiver 810 used in the present arrangement. The receiver 810 is generally composed of a demodulator 812, equalizer 814, FEC decoder 818 and transport function block 824, which includes video decoding. One skilled in the art will be familiar with the general functionality of these blocks in a DTV receiver. In this particular mobile system, FEC decoder 818 has two levels: High Latency (HL) 820, which has N iterations or cores and feeds the transport block, and Low Latency (LL) 822 with M<N iterations or cores, which feeds the equalizer to increase its performance.
[0037] FIG. 9 shows a more detailed block diagram of HL FEC 820. HL FEC 820 has a plurality of HL Cores represented by HL Corel 910, HL Core2 912, and HL CoreN 914, and as a last block, a legacy ATSC FEC block 916. Legacy ATSC FEC Block 916 includes a combination of the legacy FEC functions associated with the legacy ATSC decoder in FIG. 1, including particularly, an RS decoder, derandomizer and data interface to the transport block.
[0038] FIG. 10 shows a more detailed diagram of LL FEC 822. LL FEC 822 has a plurality of LL Cores represented by LL Corel 1010, LL Core2 1012, and LL CoreM 1014. LL FEC 822 also has as a last block, a trellis or MAP decoder 1016, since it is feeding 8-VSB symbols to equalizer 814 of FIG. 8. The main difference between the HL and LL cores is the latency of the core blocks. Because LL FEC 822 feeds equalizer 814 of FIG. 8, its functionality must be designed for minimum latency, and therefore, it may not be as robust as HL FEC 820 in performance.
[0039] FIG. 11 shows a block diagram of an HL FEC Corel-N such as HL Core 910 of FIG. 9. The input to each core consists of two streams: the first stream is the originally received stream (after demodulation and equalization), which is delayed and unaltered within each core to match the processing delay of the core and sent to the following core; and the second stream is a stream of extrinsic information associated with the received stream, as processed by the previous core. A noise estimator 918, metric generator 920 and MAP decoder 922 may be included in the HL FEC core, all of which are known in the art. Noise estimator 918 estimates the noise power in a received input stream to an HL FEC core. Metric generator 920 compares the symbols in the received input stream against the optimal 8-VSB values and calculates and stores the metrics needed by MAP decoder 922, for the specific noise power. In addition, metric generator 920 calculates, stores and passes to MAP decoder 922 extrinsic information from the previous FEC core, also called a priori metrics. MAP decoder 922 decodes the ATSC trellis code with the metrics and the a priori metrics received from metric generator 920 and produces dual- bits. [0040] Symbol to byte converter (S2B) 924 groups dual-bit outputs of MAP decoder 922 associated with each 8-VSB symbol in bytes (4 dual-bits per byte). The output of MAP decoder 922 is a soft decision version of a dual-bit, instead of 2 bits. For example, each dual-bit could be represented by 20 bits and a soft byte would then be represented by 80 bits. S2B 924 also converts the stream from symbol based to byte based.
[0041] Convolutional deinterleaver 928 is connected between S2B 924 and derandomizer 930. Convolutional deinterleaver 928 and derandomizer 930 have the same functionality as in the legacy ATSC standard as well as having the additional ability to handle soft bytes of more than 8 bits. Convolutional deinterleaver 928 rearranges the received data from a previously interleaved sequence. Derandomizer 930 derandomizes the received data to prepare the data for processing by ScaleO 936.
[0042] ScaleO 936 scales the soft bytes of the data stream received from derandomizer 930 by a chosen factor. This factor is microprocessor controlled. The scaling factor can be between 0.5 and 1.0, varying for each core. Properly chosen values optimize performance of the HL FEC.
[0043] Packet demultiplexer 940 discards legacy ATSC data and only passes DTV- M/H data to the remaining blocks.
[0044] Packet interleaver 942 receives the signals from packet demultiplexer 940 and performs block interleaving operations associated with the GF(256) SCBC block code.
[0045] SCBC decoder 946 receives data from packet interleaver 942 and performs the block decoding operation for the GF (256) SCBC blocks, as discussed previously. SCBC decoder 946 handles soft bytes, and is also a soft decision block decoder.
[0046] SCBC-to-SCBC interface 948 connects two SCBC decoders from two adjacent cores in order to pass extrinsic information and control signals from one FEC core to the next.
[0047] SRAM control 950 interfaces the packet interleaver 942, packet deinterleaver 944 and SCBC decoder 946 to an SRAM needed to perform their respective functionalities.
[0048] Packet deinterleaver 944 receives data from SCBC decoder 946 and performs the block deinterleaving operations associated with the GF(256) SCBC block code. [0049] Packet multiplexer 952 receives data from packet deinterleaver 944 and recreates a full stream with both legacy and mobile data by obtaining the mobile data from the extrinsic information received from SCBC decoder block 946 (through packet deinterleaver 944) and zeroing the legacy data, since it is not of interest to the mobile DTV decoder. The SCBC extrinsic information is used to enhance the performance of the MAP decoder of the subsequent core or iteration.
[0050] Scale 1 938 scales the soft bytes of the data stream received from packet multiplexer 952 by a chosen factor. This factor is microprocessor controlled. The scaling factor can be between 0.5 and 1.0, varying for each core. Properly chosen values optimize performance of the HL FEC.
[0051] Rerandomizer 934 is connected between Scale 1 938 and convolutional interleaver 932. Rerandomizer 934 has the same functionality as in the legacy ATSC standard as well as the additional ability to handle soft bytes of more than 8 bits. Rerandomizer 934 randomizes the received data. Convolutional interleaver 932 rearranges the received data into a sequence that is less prone to long sequences of errors.
[0052] Byte-to-symbol converter (B2S) block 926 performs the inverse functionality of S2B block 924. It separates a soft byte into soft dual-bits and converts the data from byte based to symbol based.
[0053] B2S to metric generator interface 956 obtains extrinsic information from B2S 926 and the delayed received input signals (data and sync) from the core input, and synchronizes these two sets of data with minimum latency and loss of data, outputting the two sets of data to the next core.
[0054] Equalizer to metric generator delay 954 delays the originally received data stream, field and segment sync, as well as other synchronization signals to match the overall latency of the current core blocks. In addition it passes a symbol enable from the input to the output of the core without delay.
[0055] The LL FEC core is a subset of the HL FEC core, where some of the blocks of the HL FEC core are replaced by a simpler functionality in order to decrease latency. As a result, some portions of data are lost but the remaining extrinsic information must still be synchronized with the core input data and fed to the next core. The Metric generator and MAP decoder of the LL FEC core have a reduced latency, and therefore, lesser performance than in the HL FEC core. The convolutional deinterleaver, derandomizer, convolutional interleaver, (re)randomizer, packet demultiplexer, packet interleaver, packet deinterleaver, and packet multiplexer are not present in the LL FEC core and instead are replaced by different, simplified components that perform the operations of (de)randomizing and (re)randomizing as well as extracting the mobile data of interest, which is a subset of the entire mobile data. The SCBC decoder of the LL FEC core has a different code rate than the HL FEC code rate for the purpose of decreasing the latency of the core. In addition, the Equalizer to metric generator delay block of the LL FEC core has a smaller latency than in the HL FEC core.
[0056] As discussed, an exemplary mobile DTV system is flexible enough for transmission with time diversity. The main flexibility comes from the structure of the block code (e.g., GF(256)) and the organization of segments (or packets) of data into separate blocks of information and parity packets. An information block contains information packets and possibly some parity packets, whereas a parity block contains parity packets but no information packets. In addition, a parity block may be such that the information packets can be derived from them, that is, a parity block contains a linear combination of all the information packets. These information or parity blocks can then be delayed with respect to each other before transmission. In an exemplary system, the delay can be within a range of 8 to 10 seconds to provide robust time diversity.
[0057] The present arrangement provides a time diversity scheme associated with the data and parity blocks of packets of the GF (256) SCBC encoder. As an example, a code rate of R = 12/52 is used, according to FIG. 4. Each codeword of 52 packets is split into two blocks, A and B, of 26 packets each. The A block contains 12 information packets and 14 parity packets, and is hereby called information block. The B block contains only parity packets and is hereby called parity block. As a result, information (A) and parity (B) blocks in FIG. 4 are 26 packets each and serially transmitted, where A and B jointly compose a 52 packet block out of the SCBC encoder or the packet deinterleaver. The code rate R is exemplary and may be defined as a different value, which would also result in different sized A and B blocks.
[0058] FIG. 12A shows an exemplary embodiment of a transmitter 1200 for use in a mobile DTV system supporting time diversity. The original stream without diversity out of the SCBC encoder or the packet deinterleaver and into the input to the transmitter 1200 can be represented as Data Stream 1:
I A(0) I B(0) I A(l) I B(l) I ... I A(L) | B(L) | A(L+1) | B(L+1) ... (1)
This is represented in FIG. 12A as the input to block coder 1212.
[0059] In order to add time diversity capability to the stream, the A and B blocks are first grouped in accordance with the size of the portion of the Data Field in the data burst of TABLE 1 containing the DTV-M/H Data segments. In the exemplary embodiment of TABLE 1, this portion, which is in Data Field F0, contains 156 data segments, or packets. This is the equivalent of six A or six B blocks of 26 packets each. Block coder 1212 reorganizes Data Stream 1, composed of alternating A and B blocks, into alternating groups of six, as represented by Data Stream 2: I A(0) I A(l) I A(2) I A(3) | A(4) | A(5) | B(0) | B(l) | B(2) | B(3) | B(4) | B(5) | A(6) | A(7) I A(8) I A(9) I A(10) I A(l l) | B(6) | B(7) | B(8) | B(9) | B(10) | B(ll) | A(12) ... (2) or equivalently, Data Stream 3: I AA(0) I BB(0) I AA(1) I BB(1) I ... | AA(L) | BB(L) | AA(L+1) | BB(L+1) ... (3) where AA is a block of six A blocks and BB is a block of six B blocks.
[0060] Block coder 1212 outputs the AA and BB blocks in Data Stream 3 separately and provides the BB blocks to delay buffer 1214 which delays the BB blocks relative to the AA blocks, thereby creating Data Streams 4A and 4B shown in FIGs. 12A and B. Delay buffer 1214 introduces a delay of L x 26 packets, providing an appropriate degree of time diversity (e.g., 8-10 seconds) for the broadcast medium.
[0061] Data Streams 4A and 4B are then combined at physical layer combiner 1216 by alternately taking a block from each stream to create time diversity Data Stream 5 as follows: I AA(0) I BB(-L) I AA(1) | BB(-L+1) | ... | AA(L) | BB(0) | AA(L+1) | BB(1) ... (5)
[0062] Data Stream 5 at the output of physical layer combiner 1216 is provided to transmitter block 1250 which has the ability to transfer the time diversity stream of Data Stream 5 to a receiver. Transmitter block 1250 can be implemented conventionally as a legacy ATSC transmitter, such as shown in FIG. 1.
[0063] With reference to the data burst structure of TABLE 1, Data Stream 5 is transmitted from transmitter 1200 in a sequence of data bursts in which successive data bursts (in particular, the 156 DTV-M/H Data segments in Data Field F0 thereof) contain either an AA block or a BB block, in accordance with the alternating pattern of AA and BB blocks represented by Data Stream 5. As described in greater detail below, when decoding the received data bursts at a receiver, the receiver will need to determine whether a data burst contains an A A block or a BB block. In accordance with an exemplary arrangement of the invention, a scheme is provided to facilitate this determination, thereby simplifying receiver implementation and improving receiver performance.
[0064] In an exemplary embodiment of the invention, a subset or the entirety of the RESERVED field (FIG. 2B) of the Data Field Sync segment of one or more Data Fields F0-F2 of the DTV-M/H data burst of TABLE 1 contains an indicator to identify the presence or absence of an AA or a BB block in the Data Field. The indicator is referred to herein as a data block identifier flag. This flag may be a particular pattern, data sequence, or a PN sequence, which preferably can be easily regenerated by a receiver field sync detector. If a PN sequence is used, it could be a portion of the PN511 or the PN63 sequences already used in the Data Field Sync segment (FIG. 2B) or a linear combination of these sequences. Because, as shown in TABLE 1, the DTV-M/H Data Segments signal the beginning of a burst of mobile data to the receiver, the use of such a flag in the Data Field Sync segment of Data Field F0 allows a receiver to identify the mobile data burst and to determine whether it contains an AA block or a BB block. The receiver can then process the data burst and its contents accordingly.
[0065] In an embodiment employing the exemplary DTV-M/H data burst structure of TABLE 1, the aforementioned identifier flag is placed in the Data Field Sync segment of at least one of Data Fields F0-F2, and preferably at least the Data Field Sync segment of Data Field F0. The data block identifier flag may have a first value to indicate the presence of an AA block, a second value to indicate the presence of a BB block and a third value to indicate the absence of an A A or a BB block.
[0066] In a further embodiment, the data block identifier flag can take on one of two values, which may be complementary (e.g., logical inverses of each other). To indicate the presence of an AA block in the data burst (e.g., in Data Field F0), the data block identifier flag takes on the first value and is placed in the Data Field Sync segment of Data Field F0. The second (complementary) value is placed in the Data Field Sync segments of Data Fields Fl and F2. To indicate the presence of a BB block in the data burst (e.g., in Data Field F0), the data block identifier flag takes on the second (complementary) value and is placed in the Data Field Sync segment of Data Field F0. The first value is placed in the Data Field Sync segments of Data Fields Fl and F2.
[0067] One skilled in the art will understand that there are multiple possible alternatives within the scope of the invention. For example, the data block identifier flag could be placed in Data Field Fl, and its logical inverse in Data Fields F0 and F2. In this case, the data block identifier flag would identify Data Field Fl, with the AA or BB block being in the previous Data Field F0. Likewise, the data block identifier flag could be placed in Data Field F2 and its inverse in Data Fields F0 and Fl. In this case, the flag would identify Data Field F2, and the Data Field containing the AA or BB block, F0, would be the subsequent field.
[0068] In other embodiments, AA or BB blocks for a data burst may be contained in one or more locations other than that shown in TABLE 1, including other Data Fields of the data burst. Moreover, a data block identifier flag may be placed in the Data Field Sync segment of only one Data Field of the data burst or in the Data Field Sync segment of each Data Field containing an AA or BB data block. Additionally, the placement of AA and BB data blocks within the same data burst or within the same Data Field is not precluded by the present arrangement. For example, in an exemplary embodiment, AA and BB data blocks can be arranged in any of a plurality of patterns, with each pattern having a corresponding data block identifier flag value. As an example, Data Field F0 may contain: 1) two AA blocks, 2) two BB blocks, 3) one AA block and one BB block, or 4) one BB block and one AA block. In such an example, the data block identifier flag could take on one of four values (1-4) to indicate each of the four patterns.
[0069] Transmitter 1200 includes a flag generator 1260, which in accordance with an indication from block coder 1212, generates and inserts a data block identifier flag into the RESERVED field of the Data Field Sync segment of one or more Data Fields in each data burst containing an AA or a BB block. In an exemplary embodiment based on the data burst structure of TABLE 1, flag generator 1260 will generate and insert the aforementioned data block identifier flag in the RESERVED field of the Data Field Sync segment of Data Field F0 when associated with an AA data block and its logical inverse in the RESERVED field of the DATA Field Sync segment of Data Field F0 when associated with a BB data block. Flag generator 1260 may also generate and insert logical inverses of said flag in the RESERVED field of the Data Field Sync segments of Data Fields Fl and F2.
[0070] FIG. 13A shows an exemplary receiver 1300 for the present arrangement. At the receiver, after demodulation at demodulator 1312 and equalization at equalizer 1314, delay buffer 1316 creates two versions of the transmitted stream, the first of which represents a delayed version of Data Stream 5, and the second of which represents the original stream, Data Stream 5. These two versions are represented by Data Streams 6d and 6, respectively, as shown in FIG. 13B, where Delay Buffer 1316 has a length of (2xL) x 26 packets. These two streams are then fed into FEC decoding block 1318 comprising High Latency (HL) FEC decoder 1320 and Low Latency (LL) FEC decoder 1322.
[0071] Receiver 1300 of FIG. 13 A also includes a field sync detector 1350 and a flag detector 1360. Field sync detector 1350 looks for the presence of Data Field Sync segments (FIG. 2B) in the data stream at the output of demodulator 1312 or equalizer 1314 using correlation or any other suitable method. Flag detector 1360 receives an indication from field sync detector 1350 of the presence of a Data Field Sync segment, thereby alerting flag detector 1360 to search for the possible presence of a data block identifier flag in the RESERVED field of the Data Field Sync segment.
[0072] Flag detector 1360 looks for the presence of a data block identifier flag in the received data stream at the output of demodulator 1312 or equalizer 1314. Using correlation techniques or the like, flag detector 1360 monitors the demodulated and/or equalized received data stream for a sequence of symbols matching one of the possible values of the data block identifier flag. If such a sequence of symbols is detected, flag detector 1360 provides the block identification information (e.g., AA, BB or neither) corresponding to the detected flag value to FEC decoder 1318 and equalizer 1314, accordingly.
[0073] It should be noted that Flag Detector 1360 can be implemented to detect the data block identifier flag in the received data stream without field sync detector 1350. A field sync detector, such as 1350, however, will typically be included in any receiver designed to receive data bursts with Data Field Sync segments, such as shown in FIG. 2B.
[0074] By contrast, because DTV-M/H data is FEC encoded, a conventional receiver would need to iteratively FEC decode the received data stream by multiple iterations before it can reliably detect whether a Data Field contains an AA block (or a BB block). By utilizing a data block identifier flag of the present invention, which is not FEC encoded, as described above, the exemplary receiver 1300 can identify the presence of an AA (or a BB) block rate prior to FEC decoding. The indication that a data burst contains an AA (or BB block) can thus be provided as quickly as possible to equalizer 1314 and FEC decoder 1318 which need to identify the presence of such blocks as quickly as possible.
[0075] As shown in FIG. 13 A, the detection of a data block identifier flag by flag detector 1360 is provided to HL FEC decoder 1320 and LL FEC decoder 1322. The operation of these blocks and how they employ such information will now be described with reference to FIGs. 14A and 14B.
[0076] Like HL FEC decoder 820 described above with reference to FIG. 9, HL FEC decoder 1320 comprises multiple HL FEC cores. FIG. 14A is a block diagram of an HL FEC core for use in HL FEC decoder 1320. Similarly, like LL FEC decoder 822 described above with reference to FIG. 10, LL FEC decoder 1322 comprises multiple LL FEC cores. Because the design of an LL FEC core can be a subset of the design of an HL FEC core, the description of the HL FEC core of FIG. 14 can also apply to an LL FEC core. [0077] As shown in FIG. 14 A, the HL FEC core has two separate FEC encoded inputs, PathO 1412 and Pathl 1414. In the receiver 1300 of FIG. 13A, delayed data stream 6d from Delay Buffer 1316 is processed in SubcoreO via PathO while undelayed stream 6 is processed by Subcorel via Pathl. In addition, two separate a priori output streams PathO 1416 and Pathl 1418 are delivered from one FEC core to the next, as part of the iterative FEC decoding process.
[0078] Elements similar to those in FIG. 11 are also present in the FEC Core of FIG. 14A and only the blocks associated with the GF (256) SCBC code will see the recombined stream. All similar blocks are identified by the same reference numbers found in FIG. 11. The similar blocks in FIGs. 11 and 14 are associated with most legacy ATSC FEC decoder functionalities, including trellis decoding, convolutional deinterleaving and derandomizing, as well as the reencoding counterparts. FIG. 14A also includes decoding block 1428 which contains similar blocks to those discussed with respect to FIG. 11.
[0079] As mentioned, Data Streams 6d and 6 are fed into inputs 1412 and 1414, respectively. The streams are then processed by SubcoreO 1420 and Subcorel 1422, respectively, reaching packet demultiplexer 940 at the end of each subcore. Stagger multiplexer 1430 receives Data Streams 6d and 6, as processed by subcores 1420 and 1422, and, as shown in FIG. 14B, creates one stream 7A of alternating AA blocks and zeroes and another stream 7B of alternating BB blocks and zeroes. Using the data block detection indication from flag detector 1360, stagger multiplexer 1430 generates streams 7A and 7B by extracting corresponding AA and BB blocks from Data Streams 6d and 6 and zeroing those blocks in Data Streams 6d and 6 which together do not form meaningful A&B SCBC codewords. For example, AA(0)&BB(0) form a meaningful block of SCBC codewords, but AA(L)&BB(-L) or BB(-L)&AA(L+1) do not. In addition, stagger multiplexer 1430 may also deconstruct the grouping of six A blocks and six B blocks from Data Streams 7A and 7B in order to regenerate the stream represented by Data Stream 8: I A(0) I B(0) I A(l) I B(l) |...| A(5) | B(5) | 0 | 0 |...| A(L) | B(L) | A(L+1) | B(L+1)... (8) [0080] Data Stream 8 is the same as the original stream represented by Data Stream 1, including embedded zeroes, ready to be delivered to decoding block 1424. Because zero is an SCBC codeword, it will pass unchanged through the remaining blocks in the chain.
[0081] Following decoding block 1424, stagger demultiplexer block 1432 receives Data Stream 8, and separates the A and B blocks of Data Stream 8. The blocks are regrouped according to Data Stream 2 and used to generate Data Streams 7A and 7B in order to deliver the streams back to SubcoreO 1420 and Subcorel 1422.
[0082] The grouping of A and B blocks dictates that the passing of extrinsic information from one FEC core to the next occurs as a continuous stream without interruption at the MAP decoder which results in a 0.8dB gain in Additive White Gaussian Noise (AWGN) performance over other implementations in which A and B blocks are not grouped. There is minimal loss in performance for the MAP decoder during that field of data. The loss in performance is only associated with the presence of legacy ATSC interspersed with the mobile ATSC data during the beginning and the end of the mobile data in Data Field F0 of TABLE 1.
[0083] One skilled in the art may observe that increasing the grouping of A and B blocks beyond six for this particular example may not improve performance but rather increases the latency of the receiver. This is because the DTV-M H Data portion of Data Field F0 contains only six blocks of 26 packets. Thus, the size of the grouping of blocks is a function of the size of the DTV-M/H Data portion.
[0084] FIG. 15 depicts a flowchart detailing the steps taken by the present arrangement to decode digital data. At 1512, a demodulator receives and demodulates a digital data stream including information and parity blocks. At 1514, an equalizer receives the demodulated digital data stream and compensates for distortions. At 1515, the Flag Detector (1360, FIG. 13 A) detects the presence of a data block identifier flag in the RESERVED field of a Data Field Sync segment of the incoming data burst. The Flag Detector provides the appropriate indication (e.g., AA, BB or neither) to the equalizer and the FEC decoder. At 1516, a delay buffer generates a first stream of digital data representing a delayed version of the compensated digital data stream and a second stream of digital data representing the compensated digital data stream. At 1518, the first and second streams of digital data are received and processed by a high latency FEC decoder comprising multiple cores. At 1520, each core receives the first and second streams of digital data appropriately delayed by the previous core to match its processing delay plus a third and a fourth stream of digital data corresponding to extrinsic information from the previous core. At 1522, the first and third streams feed SubcoreO and the second and fourth streams feed Subcorel of each core. Each core generates a third and fourth output stream of digital data of extrinsic information. In addition, each core appropriately delays the first and second input data stream and outputs it to the following core as a first and a second output stream. At 1524, the last core sends its decoded output stream (from the output of HL CoreN 914, FIG. 9) to a Legacy ATSC FEC unit (916) which in turn outputs an error decoded MPEG stream to the transport unit (824, FIG. 8). Finally, at 1526, the transport unit (824) delivers video/audio streams to a DTV display.
[0085] The time diversity scheme described above may be extended to include frequency diversity if, for example, the A blocks are transmitted in one frequency and the B blocks in another frequency. At the receiver, those two frequencies would be demodulated and the streams regrouped into Data Stream 5 prior to FEC decoding.
[0086] In view of the above, the foregoing merely illustrates the principles of the invention and it will thus be appreciated that those skilled in the art will be able to devise numerous alternative arrangements which, although not explicitly described herein, embody the principles of the invention and are within its spirit and scope. For example, although illustrated in the context of separate functional elements, these functional elements may be embodied in one, or more, integrated circuits (ICs). Similarly, although shown as separate elements, some or all of the elements may be implemented in a stored- program-controlled processor, e.g., a digital signal processor or a general purpose processor, which executes associated software, e.g., corresponding to one, or more, steps, which software may be embodied in any of a variety of suitable storage media. Further, the principles of the invention are applicable to various types of wired and wireless communications systems, e.g., terrestrial broadcast, satellite, Wireless-Fidelity (Wi-Fi), cellular, etc. Indeed, the inventive concept is also applicable to stationary or mobile receivers. It is therefore to be understood that numerous modifications may be made to the illustrative embodiments and that other arrangements may be devised without departing from the spirit and scope of the present invention.

Claims

CLAIMS:
1. A method performed by an apparatus to receive and process forward error correction (FEC) encoded video data in a mobile digital television (DTV) data burst, the method comprising:
detecting a data block identifier flag in a reserved portion of a data field of the data burst if the data field contains a FEC encoded data block;
generating an indication in accordance with the data block identifier flag; and processing the FEC encoded data block in accordance with the indication, including:
performing equalization of the FEC encoded data block; and performing iterative FEC decoding of the FEC encoded data block.
2. The method of claim 1, wherein the reserved portion of the data field is not FEC encoded.
3. The method of claim 1, wherein the data burst includes a plurality of data fields, at least one of which contains a FEC encoded data block.
4. The method of claim 1, wherein the data block identifier flag includes a pseudo random sequence.
5. The method of claim 1, wherein the reserved portion of the data field is contained in a data field synchronization segment of the data field, the method comprising:
detecting the data field synchronization segment,
wherein detecting the data block identifier flag is performed in accordance with the detection of the data field synchronization segment.
6. The method of claim 1, wherein the FEC encoded data block contains a plurality of information blocks.
7. The method of claim 6, wherein each information block contains a plurality of information packets.
8. The method of claim 7, wherein each information block contains a plurality of parity packets.
9. The method of claim 1, wherein the FEC encoded data block contains a plurality of parity blocks.
10. The method of claim 9, wherein each parity block contains a plurality of parity packets.
11. A method performed by an apparatus to process and transmit forward error correction (FEC) encoded video data in a mobile digital television (DTV) data burst, the method comprising:
generating a FEC encoded data block; and
transmitting a data burst with a data field containing the FEC encoded data block, including:
generating a data block identifier flag, wherein the data block identifier flag indicates that the data field contains the FEC encoded data block; and
placing the data block identifier flag in a reserved portion of the data field.
12. The method of claim 11, wherein the reserved portion of the data field is not FEC encoded.
13. The method of claim 11, wherein the data burst includes a plurality of data fields, at least one of which contains a FEC encoded data block.
14. The method of claim 11, wherein the data block identifier flag includes a pseudo random sequence.
15. The method of claim 11, wherein the reserved portion of the data field is contained in a data field synchronization segment of the data field.
16. The method of claim 11, wherein the FEC encoded data block contains a plurality of information blocks.
17. The method of claim 16, wherein each information block contains a plurality of information packets.
18. The method of claim 17, wherein each information block contains a plurality of parity packets.
19. The method of claim 11, wherein the FEC encoded data block contains a plurality of parity blocks.
20. The method of claim 19, wherein each parity block contains a plurality of parity packets.
PCT/US2009/006366 2009-12-03 2009-12-03 Data block identification in a mobile dtv system with diversity WO2011068495A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2009/006366 WO2011068495A1 (en) 2009-12-03 2009-12-03 Data block identification in a mobile dtv system with diversity

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2009/006366 WO2011068495A1 (en) 2009-12-03 2009-12-03 Data block identification in a mobile dtv system with diversity

Publications (1)

Publication Number Publication Date
WO2011068495A1 true WO2011068495A1 (en) 2011-06-09

Family

ID=44115187

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2009/006366 WO2011068495A1 (en) 2009-12-03 2009-12-03 Data block identification in a mobile dtv system with diversity

Country Status (1)

Country Link
WO (1) WO2011068495A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013165155A1 (en) * 2012-04-30 2013-11-07 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
CN104950153A (en) * 2015-05-25 2015-09-30 扬州工业职业技术学院 Wireless virtual oscilloscope realization system
CN105379205A (en) * 2013-04-23 2016-03-02 三星电子株式会社 Method and apparatus for transmitting and receiving packet in communication system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101228A1 (en) * 2003-09-29 2007-05-03 Jussi Vesma Burst transmission
US20070186143A1 (en) * 2006-01-17 2007-08-09 Rajugopal Gubbi Error Resilience Methods for Multi-Protocol Encapsulation Forward Error Correction Implementations
US20090103632A1 (en) * 2007-10-22 2009-04-23 Lg Electronics Inc. Digital broadcasting system and data processing method in digital broadcasting system
US20090190567A1 (en) * 2008-01-28 2009-07-30 Samsung Electronics Co. Ltd. Method and apparatus for transmitting and receiving broadcast service data in a broadcasting communication system, method for configuring the broadcast service data, and frame including the broadcast service data

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101228A1 (en) * 2003-09-29 2007-05-03 Jussi Vesma Burst transmission
US20070186143A1 (en) * 2006-01-17 2007-08-09 Rajugopal Gubbi Error Resilience Methods for Multi-Protocol Encapsulation Forward Error Correction Implementations
US20090103632A1 (en) * 2007-10-22 2009-04-23 Lg Electronics Inc. Digital broadcasting system and data processing method in digital broadcasting system
US20090190567A1 (en) * 2008-01-28 2009-07-30 Samsung Electronics Co. Ltd. Method and apparatus for transmitting and receiving broadcast service data in a broadcasting communication system, method for configuring the broadcast service data, and frame including the broadcast service data

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013165155A1 (en) * 2012-04-30 2013-11-07 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
CN104272627A (en) * 2012-04-30 2015-01-07 三星电子株式会社 Method and apparatus for transmitting and receiving packet in a communication system
US9106376B2 (en) 2012-04-30 2015-08-11 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
US9450702B2 (en) 2012-04-30 2016-09-20 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
US9673933B2 (en) 2012-04-30 2017-06-06 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
CN104272627B (en) * 2012-04-30 2018-03-06 三星电子株式会社 Method and apparatus for sending and receiving packet in a communications system
CN105379205A (en) * 2013-04-23 2016-03-02 三星电子株式会社 Method and apparatus for transmitting and receiving packet in communication system
US10200720B2 (en) 2013-04-23 2019-02-05 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
US10944992B2 (en) 2013-04-23 2021-03-09 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
US11317119B2 (en) 2013-04-23 2022-04-26 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving packet in a communication system
CN104950153A (en) * 2015-05-25 2015-09-30 扬州工业职业技术学院 Wireless virtual oscilloscope realization system

Similar Documents

Publication Publication Date Title
KR101532315B1 (en) High definition television transmission with mobile capability
KR101191182B1 (en) Digital broadcasting system and processing method
US8068549B2 (en) Trellis decoder for decoding data stream including symbols coded with multiple convolutional codes
JP5534528B2 (en) Apparatus and method for decoding signals
KR100811184B1 (en) Outer encoder, and, method thereof
KR101208509B1 (en) Digital broadcasting system and processing method
MX2007000438A (en) Digital broadcasting transmission/reception system having improved receiving performance and signal processing method thereof.
US20100254489A1 (en) Code enhanced staggercasting
KR20100080596A (en) Preamble for a digital television system
JP5415437B2 (en) Sign enhanced stagacasting
KR20090115045A (en) Digital broadcasting transmitter and receiver, and methods for processing streams thereof
KR101486318B1 (en) Device for generating transmit stream, digital broadcast transmitter comprising the device, and methods thereof
WO2011068495A1 (en) Data block identification in a mobile dtv system with diversity
US9391741B2 (en) Joint preamble and code rate identifier in a mobile DTV system
US9397772B2 (en) Reliable diversity architecture for a mobile DTV system
KR101648448B1 (en) Transmitting/receiving system and method of processing data in the transmitting/receiving system
WO2011068494A1 (en) Synchronization correction in a mobile dtv receiver
US8885663B2 (en) Data block processor in a mobile DTV system with diversity
US8995582B2 (en) Priori training in a mobile DTV system
WO2011068498A1 (en) Diversity architecture for a mobile dtv system
WO2011068493A1 (en) Training data strategy for a mobile dtv system with diversity
WO2011059419A1 (en) Preamble identification in a mobile dtv system
KR101092538B1 (en) Digital broadcasting transmitter and receiver
KR101086310B1 (en) Digital broadcasting receiver and stream processing method thereof
KR101085916B1 (en) Digital broadcasting receiver and stream processing method thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09851923

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 30/08/12)

122 Ep: pct application non-entry in european phase

Ref document number: 09851923

Country of ref document: EP

Kind code of ref document: A1