The present invention relates to Digital Video Broadcasting transport for hand-held devices, DVB-H, which are inherently low-power devices. More particularly, the present invention relates to a system and method for using erasure information in DVB-H.
Digital Video Broadcasting-H (DVB-H) is a new standard for providing Digital Video Broadcasting services to hand-held devices (e.g., mobile phones), see, DVB-H Implementation Guidelines, Draft ETSI TR 1XX XXX, V0.1.0, (2004-09) and DVB Specification For Data Broadcasting, Modified Version of DVB-H Additions Including CA Support, Final draft ETSI EN 301 192 V1.4.1, DVB-H201r1, the entire contents of both of which are hereby incorporated by reference. A provision is made in these guidelines/specifications to support low-power receiver implementations. For example, DVB-S, C, T information is broadcast in so-called Transport Streams in which traditionally several MPEG-2 encoded programs are multiplexed.
In order to take advantage of more advanced source-coding standards, such as MPEG-4, and to anticipate the smaller display size of hand-held devices, the video data is encapsulated in IP packets and transmitted using so-called Multi Protocol Encapsulation (MPE) sections. Referring now to
A DVB-H system is made more robust by protecting the MPE sections with an extra layer of Forward Error Correction (FEC). The additional layer of FEC makes use of a Reed-Solomon code. The RS code employed is a byte-oriented code with a Hamming distance of 65 (unpunctured version). This allows the correction of up to 32 errors (i.e., position and value of the error is unknown) or 64 erasures (errors for which the locations are known) per word of 255 bytes (unshortened and unpunctured code word). Therefore, the proper use of reliable erasure information can have a significant impact on performance.
The system and method of the present invention provide a combined scheme for using the two sources of erasure information: Reed-Solomon (RS) and Cyclic Redundancy Check (CRC).
The system and method of the present invention has the following advantages:
The system and method of the present invention thus provides multi-level erasure priorities that prevent the MPE-FEC decoder from being overloaded with erasures. At most 64 erasures can be granted, and by using several priority levels, in a preferred embodiment, the system and method of the present invention can grant the erasures in descending order of priority.
a illustrates the structure of an MPE-FEC frame;
b illustrates the sequencing of sections for transmission that corresponds to the MPE-FEC frame of
It is to be understood by persons of ordinary skill in the art that the following descriptions are provided for purposes of illustration and not for limitation. An artisan understands that there are many variations that lie within the spirit of the invention and the scope of the appended claims. Unnecessary details of known functions and operations may be omitted from the current description so as not to obscure the present invention.
The system and method of the present invention provide prioritized multi-level erasure that combines the RS and CRC sources of DVB-H soft erasure information.
Referring to
IP datagrams are placed datagram-by-datagram in the Application data table, starting with the first byte of the first datagram in the upper left corner of the table and going downwards in the first column. The length of the IP datagrams may vary arbitrarily from datagram to datagram. The maximum size of an MPE section is 4096 bytes, so that IP datagrams up to 4,080 bytes can be encapsulated (4,096 bytes—12 bytes section header—4 bytes CRC). Immediately after the end of an IP datagram, the next IP datagram starts 201 (see
The IP data is carried in MPE sections 151 in the standard DVB way, regardless of whether MPE-FEC is being used. An IP datagram is carried within one single MPE section. Referring now to
The last section of the Application data table 101 contains a table_boundary flag that indicates the end of the IP datagrams within the Application data table. If all previous sections within the Application data table have been received correctly, the receiver does not need to receive any MPE-FEC section, and if Time-slicing is used it can go to sleep without receiving and decoding RS data.
If MPE-FEC sections 152 are received, the exact number of padding columns in the Application data table is indicated with 8 bits in the section header of the MPE-FEC sections 152, and it is only if RS decoding is performed that this value is required.
The parity bytes are carried in a separate, specially-defined section type having its own table_id.
Referring now to
field generator polynomial p(x)=x8+x4+x3+x2+1, and
code generator polynomial g(x)=(x+λ0)(x+λ1)(x+λ2) . . . (x+λ63), where λ=02HEX
Each row of the Application data table contains one RS code word. Some of the right-most columns of the RS data table may be discarded, hence not transmitted, to enable puncturing. The exact amount of punctured RS columns does not need to be explicitly signaled and may change dynamically between frames. Having the RS data table 102 completely filled, the MPE-FEC frame 100 is ready to be inserted in the Transport Stream and can be transmitted.
At the receiver the MPE-FEC frame 100 must be reconstructed as well as possible to correct possible transmission errors with the MPE-FEC decoder (the RS code). The IP datagrams can be retrieved by extracting MPE sections 151 from the Transport Stream. The MPE section header signals the absolute address of the enclosed IP datagram in the Application data table 101. Similarly, the parity bytes of the RS code can be retrieved and put in the RS data table 102 by extracting MPE-FEC sections 152 from the Transport Stream. The MPE-FEC section header also contains the absolute address information of the enclosed parity column in the RS data table. Moreover, address information for the parity columns is redundant since only one parity column per MPE-FEC section 152 is transmitted and the MPE-FEC section header contains a sequence number from which the column position can be derived.
The last section of the Application data table contains a table_boundary flag, which indicates the end of the IP datagrams within the Application data table. If all previous sections within the Application data table have been received correctly, the receiver does not need to receive any MPE-FEC sections 152 and can go to sleep without receiving and decoding RS data if Time Slicing is used.
If, due to reception problems, one or more IP datagrams are not received, then the corresponding locations in the Application table can be erased, i.e., the decoder can be informed that these word positions are likely to be in error.
The MPE-FEC code has a Hamming distance of d=65, and therefore it is possible to correct up to t=32 random errors or e=64 erasures (byte positions from which the reliability information indicates that these positions are likely to be erroneous). In general, t error and e erasure decoding is possible provided that 2t+e<d.
There are two sources for erasure information, namely, Reed-Solomon decoding of the channel demodulator and a 32-bit Cyclic Redundancy Code that covers individual MPE and MPE-FEC sections. Each has shortcomings.
The RS code in the channel demodulator is a [204,188, 17] code. Traditionally, this RS code is decoded using an “error only” decoding strategy. The decoder of this code can be used for offering erasure information to the MPE-FEC. In such a mode, erasure information is given for each Transport Stream packet of 188 bytes. Erasures are assigned when the RS decoder cannot decode a word. In this event, the RS decoder sets the transport error indicator (tei) bit 301.i.1.2 in the Transport Stream packet header 301.i.1 to 1, see
The first TS packet of an MPE section contains the section header 151.1. Therefore this packet is important for knowing where to put an encapsulated IP datagram in an MPE-FEC frame 100. Therefore, when this packet is erased extra bookkeeping must be accomplished to place the remaining part of the MPE-FEC section in the MPE-FEC frame. An IP datagram fragment is defined as the part of one IP datagram that is contained in one TS packet, and when TS packets that contain intermediate parts or fragments of at least one IP datagram are erased, it becomes more difficult to build up the MPE-FEC frame. Referring now to
Referring now to
These two erasure information mechanisms each have advantages and disadvantages:
1) RS decoder
one can still allow 8 symbol (byte) error corrections and flag the corresponding word with a low-priority erasure flag (also called “soft erasure”);
2) CRC
Instead of choosing one or the other erasure information mechanism (RS or CRC), the system and method of the present invention makes combined use of these erasure mechanisms: the RS decoder of the channel demodulator acts as the basic source of erasure information and the CRC is used for modifying so-called priority levels of erasure information. A preferred embodiment employs multi-level erasure information and defines four levels of erasure information: high-priority, medium-priority, low-priority, and no-priority erasure information.
A high-priority erasure flag is assigned to TS packets that have a transport error indicator (tei) equal to 1 and/or at least one missed IP datagram fragment that occurs during an IP de-encapsulation process (TS packets that have tei=1 are ignored by the TS de-multiplexer and lead to missed parts in an IP de-encapsulation process, see, e.g., co-pending patent application by the same inventors entitled Improved IP Datagram De-encapsulation, the entire contents of which are hereby incorporated by reference). Medium-priority erasure flags are assigned to TS packets in which the RS decoder of the channel demodulator has corrected the maximum number of errors (e.g., 8). Low-priority flags are not assigned yet and therefore have no specific meaning. No-priority flags means that the corresponding TS packet (or IP datagram fragment) is not suspicious at all (the number of corrected errors is smaller than 8).
A preferred embodiment provides an erasure memory 704 comprising at least two bits of erasure information for each byte of fragment resulting in 65 kbytes (4-levels) of erasure information for one MPE-FEC frame. The erasure information is almost constant in the column direction but when carrying out the MPE-FEC decoding the erasure information in the row direction is needed since RS code words are row-oriented.
In summary, a preferred embodiment uses 4 levels (priorities) of erasure information:
Promotion of soft erasures means that they get a higher priority, i.e. when only two levels of erasures exist (soft and hard) this means that soft erasures are modified to hard erasures and fragments that are not erased get a soft erasure flag. Degradation of soft erasures means that erasures get a lower priority, i.e., when only two levels of erasure information exist one can reset the soft erasures.
Since most RS decoders that support erasure decoding can handle only two levels of erasure information (i.e., erasure or no erasure), the different levels of erasure information must be ordered and granted in decreasing order of priority. Hence, first the high-priority erasures are granted, and if space remains (at most 64 erasures can be granted) medium and low priority erasures are granted.
Referring now to
While the preferred embodiments of the present invention have been illustrated and described, it will be understood by those skilled in the art that the management frame, device architecture and methods as described herein are illustrative and various changes and modifications may be made and equivalents may be substituted for elements thereof without departing from the true scope of the present invention. In addition, many modifications may be made to adapt the teachings of the present invention to a particular situation without departing from its central scope. Therefore, it is intended that the present invention not be limited to the particular embodiments disclosed as the best mode contemplated for carrying out the present invention, but that the present invention include all embodiments falling within the scope of the appended claims.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/IB2006/050150 | 1/16/2006 | WO | 00 | 7/17/2007 |
Number | Date | Country | |
---|---|---|---|
60644542 | Jan 2005 | US |