WO2007013026A2

WO2007013026A2 - Apparatus and method for ip datagram and rs-parity encapsulation and de-encapsulation

Info

Publication number: WO2007013026A2
Application number: PCT/IB2006/052536
Authority: WO
Inventors: Onno Eerenberg; Arie Geert Cornelis Koppelaar
Original assignee: Koninklijke Philips Electronics, N.V.; U.S. Philips Corporation
Priority date: 2005-07-27
Filing date: 2006-07-24
Publication date: 2007-02-01
Also published as: TW200714083A; WO2007013026A3

Abstract

A system (1400), apparatus (1402, 1403) and method (1200-1300) are provided for improving the encapsulation and de-encapsulation of sections from Multi Protocol Encapsulation (MPE) (151) and Multi Protocol Encapsulation-Forward Error Correction (MPE-FEC) (152) Sections in a DVB-H transport stream of at least one packet (301.i). The packets have a header (301.i.1) and a payload (301.i.2) such that section headers 151.1 are not split over two consecutive TS packets (301.i) and only adaptation field 301.i.1.7 is used for stuffing 301.N.3 to fill up the TS packet payload. A maximum of one section starts in each TS packet (301.i). A resulting DVB -H transport stream including a plurality of sections (151) according to the present invention has a lower section header (151.1) loss probability.

Description

APPARATUS AND METHOD FOR IP DATAGRAM AND RS -PARITY ENCAPSULATION AND DE -ENCAPSULATION

The present invention relates to an apparatus and method for digital video broadcast handheld (DVB-H) datagram encapsulation and de -encapsulation. An IP datagram and RS parity encapsulation apparatus and method are provided that enable a more robust and less complex de-encapsulation.

DVB-H is a new European Telecommunications Standards Institute (ETSI) standard for providing Digital Video Broadcasting (DVB) services to handheld devices (e.g. mobile phones), see Digital Video Broadcasting (DVB); DVB-H implementation Guidelines, ETSI TR IXX XXX VO.1.0 (2004-09). Provisions are made in this standard to support low -power receiver implementations. As with the prior ETSI standards DVB-S, C, and T, in DVB-H information is broadcast in so-called Transport Streams in which typically several MPEG -2 encoded Programs are multiplexed.

DVB-H is based on DVB-T, and is fully backwards -compatible. DVB-H provides additional features to support handheld portable and mobile reception that allow power saving, mobility with high data rates, single antenna reception, and SFN networks, among others. DVB-H also provides impulsive noise tolerance and increased general robustness as well as support for seamless handover during power off -times.

All of the foregoing features are achieved by adding options to DVB -T including, but not limited to, time-slicing for power saving, MPE-FEC frames (explained below) for additional robustness, and 4k mode for mobility and network design flexibility. In DVB-H, data is bundled in "bursts" at a high rate so that it is possible to switch off the receiver between bursts, realizing up to 90% energy savings. Time -slicing also permits simple handover during absence of the service. In order to establish a convergence between the traditional broadcast world and the PC world, IP encapsulation is introduced. To extend this to the small multimedia devices, IP encapsulation is combined with time -slicing. DVB-H is meant for IP-based services using Multi Protocol Encapsulation (MPE). Additional robustness is provided to the DVB-H system by protecting the MPE-sections with an extra layer of Forward Error Correction (FEC) coding, thus the nomenclature MPE -FEC frame. DVB -H can share DVB-T multiplex with MPEG2 services.

An MPE-FEC frame 100 comprising an Application data table 101 and a Reed - Solomon (RS) data table 102, is specified in the ETSI standard as the transmission frame format, see FIG. 1. In a straightforward approach to IP datagram de-encapsulation, all locations in the MPE-FEC frame that correspond to an incorrectly received IP datagram are marked as erasures. Since IP datagrams can have a size up to 4080 bytes, large parts of an MPE-FEC frame may be erased in this way. Similarly, the data in the Reed Solomon data table, which is transmitted on a per column basis in so called MPE-FEC sections, can lead to erased parts of up to 1024 bytes (in general the erased parts are equal to the number of used rows in an MPE-FEC frame). So, a straightforward solution is neither effective nor efficient. An approach that re-constructs an MPE-FEC frame using fragments of received MPE section enables more advanced de-encapsulation methods.

Problems with prior DVB-H IP datagram and RS-parity data encapsulation include the lack of any limitations regarding the type of stuffing as well as the fact that a section header can be split over two consecutive transmit stream (TS) packets. Further, TS packets can contain two or more sections. These problems result from the fact that MPE is based on the usage of a private section mechanism as defined by the ISO/IEC 13818 -1 and ISO/IEC 13818-6. Within DVB, sections are used as containers for transporting SI/PSI information, which is broadcast using a data carousel. The resultant information flow is repetitive in character and due to this repetitive information character, the encapsulation of this information is optimized with respect to sections and its transportation in TS packets. As a result, TS packets can contain two or more sections. Further, due to the repetitive information character of the broadcast information, there is no need for an FEC layer on top of this information.

In order to have a simple de -encapsulation apparatus and method, especially under error-prone receiving conditions, that supports the usage of received section fragments, a technique is needed for encapsulating an IP datagram or RS -parity data at the transmission side and a de-encapsulated IP datagram or RS-parity data at the receiving side such that de- encapsulation of the received section data allows only a part of the symbols of an IP datagram and the RS-parity data to be marked as an erasure for the MPE-FEC decoder.

The system and method of the present inventi on provide an effective and efficient apparatus and method for encapsulation of IP datagram and RS -parity data for transmission in a DVB-H environment and for a de-encapsulation apparatus and method for reconstruction of received MPE-FEC frames in which erasing takes place in parts of maximal 184 bytes per TS packet..

Transmission of an IP datagram and RS-parity data in DVB-H uses Multi -Protocol Encapsulation (MPE). As a result, referring to FIG. 1, an IP datagram with a maximum size of 4080 bytes is encapsulated in a so-called MPE section 151. RS -parity data is encapsulated in a so-called MPE-FEC section 152.

The maximum IP datagram size is 4080 bytes, while a simple approach to IP datagram de-encapsulation could result in large parts of an MPE-FEC frame being erased, e.g., up to 4080 bytes for the maximum size datagram.

In the present invention, a fragment is defined as the part of one IP datagram that is contained in one TS packet, and it is assumed that a fragment memory is maintained to assist in de-encapsulation of an IP datagram. The present invention assumes that a datagram is packed into consecutive TS packets and uses the continuity counter (CC) in the TS packet header to position a received fragment in the fragment memory. Extrapolation and interpolation are also used to position a fragment in the fragment memory.

In the apparatus and method of the present invention, the encapsulation on the transmitter side of sections containing an IP datagram or RS -parity data in transport stream packets is achieved in such a way that fragments of this transport stream can be used in a reliable manner to fill a corresponding MPE-FEC frame. As already indicated, this is achieved through the use of the continuity counter (a field in the MPEG -2 transport stream header) as an address predictor in the corresponding MPE-FEC frame. Proper usage of the MPEG-2 syntax allows placement of fragments at the correct position in the corresponding MPE_FEC frame in a simple and effective way. On the transmitter side the app aratus and method of the present invention causes an IP datagram or RS -parity data to be packed into consecutive TS packets such that a section header is not split over two consecutive TS packets.

Moreover, if stuffing is required it takes place at the T S level, making section stuffing obsolete. By using the MPEG-2 syntax in this manner, a framework is created that allows the receiver side processing to employ the continuity counter in the TS packet header or the real - time parameter address in the next section header to position a received fragment(s) in the corresponding MPE-FEC frame. A more robust de -encapsulation is possible due to non- distributed section headers which reduces the probability of section header corruption during transmission. FIG. IA illustrates the structure of an MPE-FEC frame;

FIG. IB illustrates the sequencing of sections for transmission that corresponds to the MPE-FEC frame of FIG. IA.

FIG. 2 illustrates an application data table part of an MPE-FEC frame; FIG. 3A illustrates how an IP datagram of an MPE-FEC frame is broken up into TS packets for transmission using adaptation field stuffing;

FIG. 3B illustrates how an IP datagram of an MPE-FEC frame is broken up into TS packets for transmission without adaptation field stuffing;

FIG. 4 illustrates an example of unconstrained DVB -H IP section and TS packet encapsulation;

FIG. 5 illustrates an example of DVB-H encapsulation in which multiple sections are encapsulated in one TS packet;

FIG. 6A illustrates an MPE-FEC column containing correctly positioned IP datagrams. FIG. 6B illustrates an incorrectly filled MPE-FEC column containing a mix of section and IP datagram information;

FIG. 7 illustrates encapsulation of an MPE section into consecutive TS packets according the encapsulation method of the present invention;

FIG. 8 illustrates a Reed-Solomon data table of an MPE-FEC frame; and FIG. 9 illustrates a TS packet format for MPE-FEC frame transmission;

FIG. 10 illustrates how an IP datagram is broken up into MPE sections for transmission in TS packets;

FIG. 11 illustrates a Fragment Table or Fragment Memory for reconstruction of an MPE frame by a DVB-H de-encapsulator modified according to the present invention; FIG. 12A illustrates a flow chart of reconstruction of an MPE frame for a clean TS packet using the Fragment Memory by a de-encapsulator modified according to the present invention;

FIG. 12B illustrates a flow chart of reconstruction of an MPE frame for a corrupt TS packet using the Fragment Memory by a de-encapsulator modified according to the present invention;

FIG. 13 illustrates a flow chart of transfer of at least one section from fragment memory to frame memory;

FIG. 14 illustrates a DVB receiver modified to include a DVB -H de-encapsulator according to the present invention; and FIG. 15 illustrates a DVB-H dedicated network.

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 detail of known functions and operations may be omitted from the current description so as not to obscure the present invention.

The apparatus and method of the present invention provide at least one of IP encapsulation and de-encapsulation in which IP datagrams and RS -parity data belonging to the extra layer forward error correction (MPE-FEC) are respectively encapsulated and apart from correctly received sections also partly correct received sections are de -encapsulated in order to recover as much as possible from the section payload.

Referring to FIG. IA, an MPE-FEC frame 100 is a table of bytes with 255 columns and a flexible number of rows, where each row is a code word of a Reed-Solomon code. The number of rows is equal to 256, 512, 768 or 1024, and the actual used number of rows is signaled in the time_sliceje^' c_identifier_descriptor that is transmitted in PSI/SI tables (Program Specific Information/Service Information), see DVB Specification For Data Broadcasting, Modified Version of DVB-H Additions Including CA Support, Final Draft, ETSI EN 301 192 Vl.4.1, DVB-H20M. That is, the maximum allowed value for this size is 1024, which makes the total MPE-FEC frame almost 2 Mb in size. Each position in the MPE-FEC frame holds a byte. The left side 101 of the MPE-FEC frame, consisting of the 191 leftmost columns, is dedicated for IP datagrams 103 and possible padding 104, and is called the Application data table. The right side 102 of the MPE-FEC frame, consisting of the 64 rightmost columns, is dedicated to the parity bytes of the FEC code and is called the RS data table. Each byte position in the Application data table has an address ranging from 1 to 191 x No_of_rows. Similarly, each byte position in the RS data table has an address ranging from 1 to 64 x No_of_rows. Addressing in RS table is redundant, since section Jength and section jiumber are known. Referring now to FIG. IB, the IP datagrams are transmitted using so-called MPE sections 151, and the RS data is transmitted using so-called MPE-FEC sections 152.

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 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 4080 bytes can be encapsulated (4096 byte - 12 bytes section header - 4 bytes CRC). Immediately after the end of an IP datagram, the next IP datagram starts 201 (see FIG. T). If an IP datagram does not end precisely at the end of a column, it continues at the top of the following column 202. When all IP datagrams have been placed in the Application data table 101, any unfilled byte positions are padded 104-5 with zero bytes, which makes the leftmost 191 columns completely filled. The number of full padding columns 105 is signaled dynamically in each of the MPE-FEC sections (i.e. the sections that carry the RS parity bytes) with 8 bits.

The IP data is carried in MPE sections 151 in the standard DVB way, irrespective of MPE-FEC being used or not. An IP datagram is carried within one single MPE section. One Transport Stream (TS) packet payload 301 may contain one or more MPE sections 151 and one MPE section 151 may be fragmented into one or more TS packet payloads 301, in the present invention section headers are not split over two consecutive TS packets, and TS adaptation field stuffing is applied to fill up the payload of a TS packet, as illustrated in FIGs. 3A and 3B.

Referring now to FIG. 3A, adaptation field stuffing is indicated by the adaptation field control field 301.i.1.7 of the header 301.L1 (illustrated in FIG. 9), whereby the stuffing 301.N.3 precedes the remainder of the MPE section. FIG. 3B illustrates how an IP datagram of an MPE_FEC frame is broken up into TS packets for transmission when no stuffing is required.

Section stuffing, if applied, is not indicated by means of an MPEG -2 syntax element and can therefore only be found during the section parsing process. If an error occurs during the section payload recovery process, section stuffing cannot be detected reliably. Referring to FIG. 4 which shows an example according to the prior art, if packet (c) is lost or corrupted and the remaining TS packets (d), (e) and (f) are properly received they cannot be placed within the MPE-FEC frame because of the unknown number of stuffing bytes in TS packet

(f>-

In a preferred embodiment, only adaptation field stuffing is applied and the data can be stored in the MPE-FEC frame because the section CRC is at a known position (the last four positions of a TS packet payload) as a result of MPEG-2 syntax. As illustrated in FIG. 7, when TS packet (a) is not available TS packet (b) can be placed in the MPE-FEC frame because the data is seamless with respect to the data of TS packet (c) because the CRC is always at the end. Referring now to the prior art example shown in FIG. 5, data placement derived from TS packets containing multiple sections, such as (a), may result in a loss of data when TS packets are corrupted during transmission. FIG. 6A illustrates an MPE -FEC column filled with correctly received IP datagrams. Fig. 6B illustrates the same column in which IP datagrams A and B are corrupted during transmission. If the section header of the section containing IP datagram A is corrupted, the length field may not be valid . As a result, all data including the IP datagram data, the CRC and the section header data of that TS packet is stored in the MPE-FEC frame. Although data is written at MPE-FEC frame positions that are to be used by IP datagram C, this is corrected when the actual IP datagram C is processed because the section header contains the MPE-FEC start address of IP datagram C. As a result, IP datagram B is completely lost and should be recovered by means of the MPE -FEC decoder. Thus, TS packets containing multiple sections can cause error -propagation in the situation where the first section in such a TS packet is error -prone. In the system and method of the present invention the situation illustrated in FIG. 6B cannot occur and such complete loss of data is avoided through the use of a Fragment Memory 1100 that is explained subsequently.

This makes reception fully backwards-compatible with MPE-FEC ignorant receivers. Each MPE section 151 includes a start address for the IP datagram that it contains. This start address indicates the position of the first byte of the IP datagram in the application data table and is signaled in the MPE header. The receiver is then able to place the received IP datagram in the correct byte position in the Application table and mark these positions as 'reliable' for the RS decoder, provided the CRC -32 check 151.3 shows that the section is correct.

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, 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 FIG. 4, with all the leftmost 191 columns of the Application data table filled in the MPE-FEC frame it is now possible, for each row, to calculate the 64 parity bytes of the RS data table 103 from the 191 bytes of IP data and possible padding. The code used is a byte-oriented [255,191,65] Reed-Solomon code with

field generator polynomial p(x) = x^ + x^ + χ3 + χ2 + i and code generator polynomial g(x) = (x+λ")(x+λ^)(x+λ^)...(x+λ"^), where λ = 02j_jjjχ

Each row of the Application data table contains one RS codeword. Some of the rightmost columns of the RS data table may be discarded and hence not transmitted, to enable puncturing. The exact amount of punctured RS columns can be determined from the last section number field in the MPE-FEC section header and may change dynamically between frames. Having the RS data table 102 completely filled, the MPE-FEC frame 100 is ready for being inserted in the Transport Stream and can be transmitted.

At the receiver the MPE-FEC frame 100 has to be reconstructed as good as possible in order to correct possible transmission errors with the MPE-FEC decoder (the RS code).

The IP datagrams are 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 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 data 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 / = 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, / error and e erasure decoding is possible provided that 2t + e < d.

Before the MPE-FEC decoding can start the MPE-FEC frame has to be rebuilt. This means that IP de -encapsulation has to be done and the RS parity information has to be gathered. IP datagrams are encapsulated in MPE sections 151. The MPE section header gives information about the section length and the address of the IP datagram in the

Application data table 101. The section length is related to the IP datag ram length, it equals the IP datagram length + section header length (=12 bytes) + CRC length (=4 bytes). For

MPE-FEC sections length calculation is similar and is equal to RS parity data length + section header length (=12 bytes) + CRC length (=4 bytes).

Below some situations are sketched that make the reconstruction of an MPE -FEC frame more difficult.

Referring now to FIGs. 3 A and 3B, an example of IP de -encapsulation is illustrated. In this example, an MPE section 151 is distributed over N TS packets 301. The section header 151.1 and a part of the IP Datagram 151.2 is present as the payload 301.1.2 in TS packet 1 301.1. The rest of the IP datagram and the 32 -bit CRC is present in TS packet 2 301.2 up to Ν 301.Ν. Transmission errors may complicate correct re-building of the MPE- FEC frame 100. The following situations are identified:

1. TS packet 1 301.1 is erroneous and the transport error indicator (tei) in the TS packet header 301./.1.2 for i = 1 (see FIG. 9) is set to 1 by the RS decoder in the channel decoder, indicating that the RS decoder was not capable of correcting the TS packet. In this case the section header can be corrupted and no reliable information about section length and Application Data table addressing is available. Most implementations of a TS demultiplexer will discard TS packets with tei = 1 and therefore the section header will (can) not be processed, leading to a lack of both address information and section length information. One consequence is that the payload of TS packet 2 up to N cannot be put directly in the MPE-FEC frame, even if these packets are received correctly, because table address information is lacking. A straightforward implementation of an IP de-encapsulator, as described above, ignores TS packets 2 through N and waits for the next MPE section header and leads thus to error propagation.

2. TS packet 1 is erroneous but the transport error indicator is set to zero (miss-correction of the RS decoder). Somewhere in the TS packet there must be an error. If the error is in the PID (packet identifier) field, the packet will not be selected by the TS de-multiplexer. See also 4.

3. TS packet 1 is correct, but one or more of the other TS packets is erroneous. In this situation, the section length as well as the Application Data table addressing is reliable. With the aid of the continuity counter in the header of correct TS packets, one can try to erase the fragments of the IP datagram that are in the erroneous TS packets.

4. None of the N TS packets is detected to be erroneous by the RS decoder, but the CRC fails. In this case, one (or more) miss-detection(s) of the RS decoder took place, but after all it is impossible (difficult) to find out which of the TS packets is in error. So, it can also be the first TS packet such that section length and

Application Data Table addressing becomes unreliable. If one completely trusts an erroneous section length one can encounter propagation problems to the next MPE sections (section length too long can result in a missed section header of th e next section). Such a situation occurs when multiple sections are carried within one TS packet. Error propagation is limited due to the payload unit start indicator, which indicates where the first byte of the first section starts in a TS packet.

5. One of the TS packets 2 through N is not filtered (selected) by the PID filter due to an error in the PID value resulting in a cap.

6. Due to an error in the PID value, an unwanted TS packet is considered to be a wanted TS packet (value 2 through Ν). An insertio n error can be detected by observing the continuity counter in the TS packet header. An insertion or deletion error will probably be accompanied with a transport error indicator equal to one.

FIG. 10 illustrates some of the various ways that sections can be embedded in the payload of TS packets. The pointer field 301.i.2.1 indicates the first byte of a new section and is present only for the first new section in a TS packet (indicated with the payload _unit_start_indicator in the TS packet header). The maximum IP datagram size is 4080 bytes, while a TS packet can contain at most 184 bytes of payload. A fragment is defined as the part of one IP datagram that is contained in one TS packet.

Assuming that the datagrams are packed into consecutive TS packets as efficiently as possible, one can expect that a maximum length IP datagram is divided into approximately

N = I 1 = 23 fragments .

¹ 184 ' ^{J S}

Moreover, in the present invention, the use of a TS continuity counter (CC) in the TS packet header also decreases error propagation (borders of sections) and detects anomalous effects before a cyclic redundancy check CRC is calculated. From a received TS packet, the IP fragment is put in the Fragment Memory. The Fragment Memory is memory in which fragments of an IP datagram are stored until the reception of an IP datagram is completed. Using the continuity counter (CC) in the TS packet header it is possible to determine (to a certain degree of certainty) the position of the fragment (i.e. the fragment pointer) in the Fragment Memory. A single missed fragment can also be detected. Note that the continuity counter is a 4-bit counter, so its effective range is limited .

Fragments can vary in length due to stuffing. In the case of private sections, see, e.g., ISO/IEC 13818-1, Information Technology - Generic coding of moving pictures and associated audio information : Systems, 2^nd edition 2000-12-01, two mechanisms can be used for stuffing. If adaptation fields are used for stuffing, this is signalled in the Transport Stream header. With adaptation fields, the stuffing takes place before the actual payload. Another form of stuffing is dedicated to PSI and private sections (hence also MPE sections). In that case stuffing takes place after the last byte of a section, and a new section starts in the next TS packet with a pointer field having value zero. To facilitate the de-encapsulation, in a preferred embodiment only adaptation field stuffing is employed. If stuffing 301.N.3 is required it takes place in the last TS packet 301.N, i.e. the one containing the last fragment 301.N.2 of the IP datagram and the 4 byte CRC 151.3. In this way, if intermediate fragments are lost, the last part of the IP datagram can be placed correctly in the MPE -FEC frame using the MPE-FEC frame address of the next IP datagram. Assuming that the last received fragment belongs to the same IP datagram, it is possible to extrapolate the fragment address from the address information that is available in the section header using the section length. If these fragments do not belong to the same IP datagram (the section length gives an idea about how many fragments are needed for the IP datagram, this can be used for determining whether a received fragment belongs to the same IP datagram) the table address of the (very) next section header can be used and these fragments can be placed just before the next start of the next IP datagram. Correctly received fragments that are between the first and the last missed fragments are called floating fragments. In principle, floating fragments lack address information. If all fragments (except the first and the last) have the same length, address interpolation can be used to obtain the address of the floating fragments. Otherwise more advanced techniques are needed (e.g. partial decoding of the MPE-FEC frame such that one can estimate the position of the floating fragments).

Since the fragments of IP datagrams belong to different TS packets, they can have different levels of soft erasure information (e.g. the numb er of corrected errors). The CRC calculation is only beneficial if no missed fragments are detected.

In a preferred embodiment, erasing takes place in units of 184 bytes (payload of TS packet). Moreover, the use of the TS continuity counter also decreases error propagation (borders of sections) and provides detection of anomalous effects before the CRC is calculated.

FIGs. 12A-B illustrate a flow diagram of IP de -encapsulation of a preferred embodiment for a non-corrupt, i.e., clean TS packet and a corrupted TS packet, respectively. Prior to placing an IP datagram into an MPE frame, fragments of the IP datagram are put into a scratch memory called a Fragment Memory, see FIG. 11. For both clean TS packets and when corrupted TS packets are received the Fragment Memory provides an efficient way of reconstructing an IP datagram.

In the flowchart of FIG. 12A it is assumed that the time -sliced service that is selected by the user has PID value "A".

At step 1201, the TS packet header 301.i.l is read. At step 1202, the packet identifier is checked to see if it is equal to "A". An elementary stream, (e.g. a time -sliced service) is characterized by the PID value in the TS header. In PSI (Program Specific Information) tables a mapping between elementary streams and PID values is made, such that a receiver on the basis of this table can see what the PID value is of the desired elementary stream. In FIG. 12A, the value "A" stands for the PID value of the desired time -sliced service. If it is not the desired service, then the next TS packet header is read by performing step 1201. If the Packet IDentifier (PID) is equal to "A", then at step 1203 if the transport error indicator (tei) is on, then corrupted TS packet processing is performed beginning at step 1221 of FIG. 12 B, since the current packet contains errors.

If the tei indicator is off at step 1203 clean TS packet processing is performed beginning at step 1203 the payload unit start indicator (pusi) is checked to see if a new section starts.

At step 1206, if no new payload is starting, then at step 1206 the continuity counter (CC) is checked against the shadow counter (SC), and if CC=SC, then step 1214 is performed. If CC≠SC at least one packet has been missed (pusi==0, means that no new section header is starting in the payload of the TS packet and therefore IP de -encapsulation of the current IP datagram is proceeded by retrieving a new fragment).

At step 1208, the discontinuity counter is incremented (DC:=DC+1) and both the missed fragment counter (K) and the Fragment Pointer (FP) are incremented with the difference Mod(16) between the continuity counter (CC) and the shadow counter (SC), and the Last Missed Fragment (LMF) is set to the new value of the Fragment Pointer (FP) -1, since more than one fragment (i.e., TS packet) could have been missed (lost). If this is the First Missed Fragment, i.e., FMF is null at step 1210, then at step 1212 the First Missed Fragment (FMF) is set to the fragment pointer FP-I and the shadow counter (SC) is set equal to the continuity counter (CC). Regardless if this is the First Missed Fragment or not, the current fragment is not in error and step 1214 is performed. Counter (K) counts the number of missed fragments based on the difference between the continuity counter (CC) and the shadow counter (SC). The discontinuity counter (DC) counts the number of discontinuities. From the value of DC one can derive the number of floating groups of fragments (a group is at least one or more consecutive fragments that are floating) , i.e. F := DC -1

At step 1214, the current payload is stored in the Fragment Memory (FM) at the location indicated by the Fragment Pointer (FP), the Fragment Pointer is incremented to the next fragment (FP:=FP+1) in the Fragment Memory (FM), and the shadow counter (SC) is incremented by one (SC:=SC+1). The next TS packet header is then read by performing step 1201.

At step 1205, when a new section is starting (pusi ≠ 0), the pointer field of the TS header is checked to see if the new section starts direct Iy after the Pointer Field (pointer field = 0) and if so step 1218 is performed (this corresponds to the situation illustrated in the first row of FIG. 10). Otherwise (Pointer Field ≠O) the last fragment of the current section (or IP datagram) is retrieved from the TS packet payload (step 1207 etc) before the section header of the new section is read (step 1218). "pusi" stands for Payload Unit Start Indicator and this flag signals the start of a new payload (section) somewhere in the payload of a transpo rt packet. The Pointer Field (PF) points to the position in the transport packet (see FIG. 10) where the new section starts.

At step 1218, the section header in the TS packet payload (pointed at by the pointer field of the payload) is read. The contents of the Fragment Memory are transferred to an Application data table for an MPE-FEC frame (MFF) at step 1220, because receipt of an IP datagram is completed. Reception of an MPE-FEC frame is completed after all IP datagrams (signalled with a table-boundary flag) and all RS -data columns (signalled with a frame - boundary flag) are received. Then MPE-FEC decoding can start. After MPE-FEC decoding is finished, the Application data table (i.e. the IP datagrams) can be transferred to the Application Engine (kind of host processor on which the actual application runs in a mobile/portable device), the shadow counter (SC) is set to the continuity counter (CC) plus 1 (SC:=CC+1), the Fragment Pointer (FP) is reset to zero, and the First Missed Fragment (FMF) and Last Missed Fragment (LFM) are both reset to null. Then step 1201 is performed to read the next TS packet header.

If, at step 1205, the Pointer Field (PF) of the TS packet payload is not zero, then the payload contains apart from a (new) section header, also a remainder from the current section (see row 3 of FIG. 10) and the continuity counter (CC) should be equal to the shadow counter (SC) at step 1207 or at least one packet has been missed. If at least one packet has been missed then steps 1209 through 1213 are performed to record the at least one packet as missing, the Fragment Pointer (FP) is adjusted to the fragment following the missed packets, and the shadow counter(SC) is set equal to the continuity counter (CC). In either case, at step 1215 the payload is stored in the Fragment Memory (FM) at the location indicated by the Fragment Pointer (FP). At step 1216, if the First Missed Fragment (FMF) is null and the corrupt section indicator (csi) is zero, indicating that the contents of the Fragment Memory (FM) are correct, then CRC processing is performed at step 1217. Then, in any event, step 1218 is performed to read the section header that is contained in the TS packet payload., The shadow counter (SC) is meant for detecting discontinuities in the Transpo rt Stream (distorted TS packets). If both the end of a section and the start of a new section are missed then the payload that is written to the Fragment Memory will belong to two or more different IP datagrams. In this case the Fragment Memory can be too small. By calculating the expected number of fragments (using the section length) it is possible to get some indication whether or not the payload belongs to two or more IP datagrams. This can also have consequences for the way fragments are put in the MPE-FEC frame (address interpolation and extrapolation). When tei=l, corrupt TS packet processing performed beginning at step 1203, extra consistency checks are performed beginning at step 1221 of FIG. 12B. First, csi is set equal to 1 at step 1221. Then, at step 1222 when a new section header is starting (pusi ≠ 0), the pointer field of the TS header is checked at step 1229 to see if the new section starts directly after the Pointer Field (pointer field = 0) and if so step 1237 is performed (this corresp onds to the situation illustrated in the first row of FIG. 10). Otherwise (Pointer Field ≠O) the last fragment of the current section (or IP datagram) is retrieved from the TS packet payload (step 1230, etc.) before the section header of the new section is read (step 1237). "pusi" stands for Payload Unit Start Indicator and this flag signals the start of a new payload (section) somewhere in the payload of a transport packet. The Pointer Field (PF) points to the position of the new payload (section) in the transport packet (see FIG. 10) at which the new sections starts.

At step 1237, the section header in the TS packet payload (pointed at by the pointer field of the payload) is read and checked for consistency at step 1238. This consistency check of the section header can be accomplished by examining some pre -determined fields in the section header which have been set to a pre -determined value or a value that can be predicted, such as a Table address. Of the new section header passes the consistency check of step 1238, the contents of the Fragment Memory are transferred to an Application data table for an MPE-FEC frame (MFF) at step 1239, because receipt of an IP datagram is complete at this point in the processing. Reception of an MPE-FEC frame is complete after all IP datagrams (signalled with a table-boundary flag) and all RS -data columns (signalled with a frame - boundary flag) are received. Then MPE-FEC decoding can start. After MPE-FEC decoding is finished, the Application data table (i.e. the IP datagrams) can be transferred to the Application Engine (kind of host processor on which the actual application runs in a mobile/portable device), the shadow counter (SC) is set to the continuity counter (CC) plus 1 (SC:=CC+1), the Fragment Pointer (FP) is reset to zero, and the First Missed Fragment (FMF) and Last Missed Fragment (LFM) are both reset to null. Then step 1201 is performed to read the next TS packet header.

However, if the header fails the pre -determined consistency check at step 1238 then at step 1240 the shadow counter (SC) is set to the continuity counter (CC) plus 1 (SC:=CC+1) and csi is set to one (csi:=l). Then step 1201 is performed to read the next TS packet header.

If, at step 1229, the Pointer Field (PF) of the TS packet payload is not zero, then the continuity counter (CC) should not differ too much from the shadow counter (SC). That is, at step 1230 CC should be in the range [SC, (SC+l)modl6, ,„ , (SC+Delta)modl6] where Delta is a pre-set parameter. If Delta=0 then strong consistency is required and if Delta=15 then poor consistency is required. The consistency check of step 1230 is added because the CC field in the TS packet header may be corrupted when tei=l . The payload contains, apart from a (new) section header, a remainder from the current section (see row 3 of FIG. 10) and the continuity counter (CC) should be equal to the shadow counter (SC) at step 1231 or at least one packet has been missed. If at least one packet has been missed then steps 1232 through 1235 are performed to record the at least one packet as missing, the Fragment Pointer (FP) is adjusted to the fragment following the missed packets, and the shadow counter (SC) is set equal to the continuity counter (CC). Regardless whether or not SC=CC, at step 1236 th e payload is stored in the Fragment Memory (FM) at the location indicated by the Fragment Pointer (FP). Step 1237 is performed to read the new section header.

In the flow chart of FIGs. 12A-B, distributed section headers (i.e. section headers that are distributed over two TS packets) are not considered because in a preferred embodiment distributed section headers are not allowed. More than one section can be present in a TS packet and one skilled in the art will be able to readily accomplish this adaptati on in FIGs. 12A-B. The result of the CRC processing is used for assigning erasures.

Referring now to FIG. 13, a flow is illustrated for the transfer of the fragments stored in columns 1106.i of the Fragment Memory 1100 to an MPE-FEC frame memory 1404. The number of missed fragments is K. The number of floating groups of fragments is F.

L_RF is the sum of the lengths of the received fragments.

Lsc is the length of the section payload - (e.g., length of IP datagram). This discussion and procedure is meant to apply to both MPE and MPE-FEC sections. IP Datagrams are used and an example only for explication. At step 1302 a test is made to determine if there are missed fragments (K>0?). If there are no missed fragments (K=O), all the fragments 1106.i of the Fragment Memory 1100 are placed directly in the MPE-FEC frame memory 1404 at step 1303. There is no address ambiguity because the fragments in the Fragment Memory 1106.i are placed consecutively in the MPE-FEC frame memory 1404. At step 1302, if K>0 there are missed fragments but the length of the missed fragments is not known. If no Adaptation Field stuffing is used, the payload of a TS packet is completely used for section data, i.e., a missed fragment should have length 184 bytes. Therefore, whether L_RF + K* 184 <= L_Sc is tested at step 1304 and if no Adaptation Field stuffing is used then the presence of floating fragments is tested at step 1305. If no groups of floating fragments are present (F=O) the missed fragments are consecutive and th ere is a gap in the section (e.g., IP Datagram) whose fragments 1106.i are stored in the Fragment Memory 1105. Then, the length of the gap is determined as the difference of the section payload length and the length of all received fragments and is determined at step 1307 as

At step 1313 the length of the missed fragments is set equal to ΣL_MF.

At step 1310 erasure information is assigned to the missed fragments and the floating fragments and the missed fragments are erased. Then, the received fragments together with the (consecutive) missed fragments are placed consecutively in the MPE-FEC frame 1404 using the MPE-FEC frame table address which is contained in the received section header 1105 that is stored in the Fragment Memory 1100. If there is at least one group of floating fragments, i.e., at step 1305 F≠O, there are at least two missed fragments: at least one before and at least one after the at least one group of floating fragments. At step 1306 it is determined if these missed fragments have length 184 bytes (maximum packet payload length) by testing whether

L_RF + K*184 = = Lsc

If so, at step 1308 all the fragment lengths 703.i are assigned the maximum length of a fragment, i.e., 184 bytes and step 1310 is performed such that all the fragments 1106.i inclusive of the floating fragments are placed in the MPE-FEC frame 1404 by using a missed fragment length of 184 and placing the fragments 1106.i consecutively in the MPE -FEC frame 1404 and assigning erasure information to the missed fragments and floating fragments.

If the missed fragments are not all 184 bytes in length, i.e., the test at step 1306 fails, at least one of the missed fragments has a length <184. Since there is no way to know which of the missed fragments has a size smaller than 184 it cannot be determined where to place the floating fragment(s) into the MPE-FEC frame 1404. Therefore, at step 1311 both the missed and floating fragment(s) are erased and the combination of missed and floating fragment(s) is a gap (hole) in the section (e.g., IP datagram). At step 1311, the remaining received fragments (just after the section header and just before the CRC) can be placed in the MPE-FEC frame 1404 using the section length 1105.1 and the MPE-FEC frame table address 705.2 in the section header 1105. If, at step 1404, L_RF + K* 184 > L_Sc, then one or more section headers have not been received or have been incorrectly received and the Fragment Memory 1100 contains fragments 1106.i of more than one section, e.g., IP datagram. This can also be detected using the Continuity Counter (CC) and the section length 1105.1. The number of TS packets needed for transferring a section, e.g., an IP datagram, of size L is approximately L/184, which is the difference between the CC value 301. i.1.8 of the TS packet containing the last fragment and the CC value 301. i.1.8 of the TS packet containing the first fragment (CC is assigned modulo 16, so allowance has to be made for wrap-around). In this case, the fragments that were received directly after the section header 1105 are placed in the MPE- FEC frame 1404 using the MPE-FEC frame table address 1105.2 which is present in the section header 1105 stored in the Fragment Memory 1100. At step 1412, the fragments received just before the CRC and a new section header belonging to another IP datagram are placed in the MPE-FEC frame using the MPE-FEC frame table address 1105.2 that is present in the new section header. This is possible since it is known that these last fragments and the fragments of the new section, e.g., IP datagram, should be placed consecutively in the MPE- FEC frame. However, too many uncertainties remain concerning the floating fragments to locate them in the MPE-FEC frame 1404 and erase the corresponding places.

Referring now to FIG. 14, a transmitter 1402 is shown comprising an IP-encapsulator 1404 modified according to the present invention so that there is adaptation field stuffing only and no splitting of section headers and a receiver 1403 is shown comprising a de-encapsulator

1401 modified according to the present invention to use a fragment memory 1100 to limit lost parts to 184 bytes. Note that only the receiver needs to be modified, and an MPE -FEC ignorant receiver simply ignores MPE-FEC sections so that support for MPE-FEC is not mandatory. FIG. 15 illustrates a DVB-H dedicated network in which the DVB-H transmitters

1402 and receivers 1403 may be modified according to the present invention to allow exact location of received IP datagrams and RS -parity data fragments limiting the amount of MPE loss to 184 byte parts or a multiple of this value.

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 modifi cations 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 with the scope of the appended claims.

Claims

CLAIMS:

1. A system (1400) including a transmitter (1402) for transmission of a section (151)(152) in a generated sequence of at least one consecutive transport stream (TS) packet (301.i) having a header (301.1.1) and a payload (301.i.2), comprising: an encapsulator module (1405) for generation of a sequence of at least one consecutive transport stream (TS) packet (301.i) having a header (301.i.l) and a payload (301. i.2) comprising: a section header (151.1) such that said section header (151.1) is contained in exactly one of said consecutive TS packets (301.i) of said sequence, and a TS packet header adaptation field (30 Li.1.7) that is used to stuff the payload of the TS packet (301.i.3) to fill up the at least one consecutive TS packet payload (301. i.2).

2. The system (1400) of claim 1, wherein said generated sequence comprises a DVB-H transport stream of at least one DVB-H TS packet having a plurality of sections (151X152).

3. The system (1400) of claim 1, wherein the packet header (301. i.l) includes a Packet Identifier (PID) (301.i.5) having a pre -determined value.

4. A method for transmitting a section (151)(152), comprising the steps of: generating a sequence of at least one consecutive transport stream (TS) packet (30Li) having a header (30Li.1) and a payload (301.L2); encoding said section header (151.1) in exactly one of said consecutive TS packets (30Li) of said sequence, and including in said TS packet header an adaptation field (30Li.1.7) to indicate stuffing is present in the payload; stuffing the payload of the TS packet (301.i.3) to fill up the at least one consecutive TS packet payload (301.i.2) such that a TS packet comprises at most one section header (151.1).

5. The method of claim 4, wherein said generating step further comprises the steps of generating a DVB-H transport stream including at least one DVB-H TS packet having a plurality of sections (151)(152).

6. The method of claim 4, further comprising the step of including in the packet header (301.i.1) a Packet Identifier (PID) (301.i.5) having a pre -determined value.

7. The system (1400) of claim 1, further comprising a receiver apparatus (1403) for reconstruction of a section (151) (152) received in a sequence of at least one packet (301.i) having a header (301.L1) and a payload (301.i.2) of maximum length M, comprising: a fragment memory (1100) comprising a plurality of numbered (HOl.i) fragment columns (1106.i) of length M having an associated length variable (1103.i) , wherein a fragment (1001) is a part of a section (151) (152) contained in a payload (301.L2) such that a sequence of at least one fragment (1001) is contained in the received sequence of at least one packet (301.i); a frame memory (1404) for storing the reconstructed section (151) (152) a de-encapsulator module (1401) to reconstruct the section (151) (152) in the order of the received sequence of at least one fragment (1001), wherein a. prior to reconstruction of a section (151) (152) a corrupt section indicator is reset to 'off and each associated length variable (1103.i) is set equal to zero and a fragment pointer (FP) is set to zero; b. when a fragment (1001) of the sequence having a length ' /' is contained in a packet (301.i) that is received correctly, the fragment (1001) and the length T of the fragment (1001) is stored in a column ' /' (1106.1) and the length '/' is stored in the associated length variable (1103.1) ; c. when a fragment (1001) of the sequence is contained in a packet (301.i) that includes an un-correctable error, the fragment (1001) and the length ' /' of the fragment (1001) is one of stored in a column (1106.i) along with its associated length (1103.1) variable and ignored, based on a pre -determined consistency criteria and the corrupt section indicator is set to 'on'; and d. store the fragments (1106.i) of the fragment memory (1100) having a reliable frame address information in the frame memory (1404) beginning at a table address (1105.2) received in a payload.

8. The system (1400) of claim 7, wherein an un -correctable error is indicated by a transport error indicator (301.i.1.2) included in a packet header (301.i.1).

9. The system (1400) of claim 7, wherein the packet header (301.i.1) includes a Packet Identifier (PID) (301.L5) to indicate a service type of the packet(301.i) and the de - encapsulator (901) is further configured to ignore the packet (301.i) in accordance with a predetermined PID acceptance scheme.

10. The system (1400) of claim 7, wherein: the fragment memory (1100) is further configured to have an erasure information (1102.i) associated with each column (1106.i); and when all fragments (1001) of a sequence have been one of stored in the fragment memory (1100) or ignored, the de-encapsulator module (1401) is further configured to: e. when there are missing fragments indicated by a fragment column (1106.i) having an associated length variable (1103.i) of 0, set the associated erasure information (1102.i) to a predetermined value, and f. when there are no missed fragments and the corrupt section indicator is set to 'off, process (1217) a CRC received in a payload of the sequence and set the erasure information (1102.i) for each column based on the result of the CRC.

11. The apparatus (1400) of claim 7, wherein: the fragment memory (1100) further comprises a fragment pointer (FP) (1101) pointing at the next fragment column (1106.i) to receive a fragment; the packet header (301.i.l) comprises a continuity counter (CC) (30 Li.1.8) that cycles from 0 to k to signal lost packets of a sequence; the de-encapsulator module (1401) is further configured to- e. maintain (1212-1214) (1227-1228) (1235) (820) a shadow counter (SC) to track an expected value of CC, initialize SC=CC for each section received, and enforce the pre-determined consistency criteria of SC=CC, f. maintain (1208) (1209) (1225) (1232) a discontinuity counter (DC), a missed fragment counter (K) and a floating fragment group counter (F), g. when a packet is one of

(1) received correctly, and

(2) includes an un-correctable error and CC=SC, respectively store (1214, 1215) (1228, 1236) the payload fragment at the column of the fragment memory pointed at by FP and then adjust FP and SC to respectively point at the next column to receive a fragment and the value of CC expected in a next packet of the sequence. h. when a packet (301.i) includes an un-correctable error, CC≠SC, and CC is within a predetermined range of SC, to respectively store (1214, 1215) (1228, 1236) the payload fragment at the column of the fragment memory pointed at by FP and then adjust FP and SC to respectively point at the next column to receive a fragment and the value of CC expected in a next packet of the sequence), otherwise to ignore the packet such that the fragment is a missing fragment.

12. The apparatus (1400) of claim 11, wherein an un-correctable error is indicated by a transport error indicator (301.i.1.2) included in a p acket header (301.i.1).

13. The apparatus (1400) of claim 12, wherein the packet header (301. i.l) includes a Packet Identifier (PID) (301. i.l.5) to indicate an service type of the packet and the de-encapsulator module (1401) is further configured to ignore the packets (301. i) in accordance with a pre-determined PID acceptance scheme.

14. The apparatus (1400) of claim 13, wherein the de-encapsulator module (1401) is further configured to prior to storing a received fragment when CC≠ SC to advance FP and K by ((CC-SC)(modulo 16), set SC=CC, increment DC, record a last missed fragment (LMF) as a column just prior to FP and if a first missed fragment (FMF) is null to set FMF=LMF (1208-1213) (1225-1227, 1232-1235).

15. The apparatus (1400) of claim 14, wherein: the fragment memory (1100) is further configured to have an erasure information (1102.i) associated with each column (1106.i); and when all fragments (1106.i) of a sequence (1001) have been one of stored in the fragment memory (1100) or ignored, the de-encapsulator module (1401) is further configured to: i. when there are missing fragments indicated by a fragment column (1106.i) having an associated length variable (1103.i) of 0, set the associated erasure information (1102.i) to a predetermined value and set the group counter F to a number of floating group fragments = DC-I, j. when there are no missed fragments and the corrupt section indicator is set to

'off, process a CRC received in a payload of the sequence and set the erasure information (1102.i) for each column based on the result of the CRC, and k. store fragment memory (1106.i) in the frame memory (1404) in accordance with a pre-determined storage scheme based on the values of K and F.

16. The apparatus (1400) of claim 15, wherein the pre-determined storage scheme is as follows: when K = 0 the fragment memory is stored at the address in the frame memory (1404) indicated by a table address (1105.2) received in a section header (151.1) and stored in a section header (1 105) of the fragment memory (1100); when K ≠ 0 and at least one fragment of a current section and a next section (151) (152) is stored in the fragment memory, a table address of a section header of the next section is used to store the fragments (1106.i) of the fragment memory (1100) in the frame memory (1404); when K ≠ 0 and fragments (1106.i) from only one section (151) (152) are stored in the fragment memory (1100), the length of the missed fragments is determined based on an adaptation field stuffing and using this length each fragment (1 106.i) of the fragment memory (1100) is stored consecutively at the address in the frame memory (1404) indicated by a table address (1105.2) received in a section header (151.1) and stored in a section header (1105) of the fragment memory (1100).

17. The apparatus (1400) of claim 16, wherein when F ≠ 0 and the length of missed fragments is not fixed, the missed (1107) (1109) and floating fragments (1108) are erased from the fragment memory (1100) prior to storing the fragments (1106.i) of the fragment memory (1100) in the frame memory (1404).

18. A digital video broadcasting system (1400) for handhelds (DVB-H) comprising: an encapsulator module (1404) for generation of a sequence of at least one consecutive transport stream (TS) packet (301. i) having a header (301. i.l) and a payload (301.L2), comprising: a section header (151.1) such that said section header (151.1) is contained in exactly one of said consecutive TS packets (301.i) of said sequence, and a TS packet header adaptation field (30 Li.1.7) that is used to stuff the payload of the TS packet (301. i.3) to fill up the at least one consecutive TS packet payload (30112), wherein, a TS packet (30Li) comprises at most one start of a section (1003); a memory comprising a plurality of columns each having a. M rows, b. an erasure information (1102.i), c. a fragment length (1103.i), and d. a fragment pointer value ( 110 Li), to receive at a column having a fragment pointer value equal to a Fragment Pointer (FP) pointing to the next column to receive a fragment, one of a valid fragment of a reconstructed section, a fragment containing an un-correctible error, and to remain empty according to a pre -determined consistency criteria, wherein M is the maximum number of bytes in a packet payload; and a de-encapsulator module (1401) comprising a configuration for reconstruction of a section (151) (152) from a sequence of at least one section fragment received in a packet (30Li) and stored consecutively as a fragment (1106.i) having a length (7O3.i) and an erasure information (1102.i) at FP in the memory (1100), wherein a fragment is defined as a part of a section (151) that is contained in one packet (30Li) and FP is set to the next fragment storage location (110Li) in the fragment memory (1100).

19. The DVB-H system (1400) of claim 18, wherein: said received packet (30Li) includes a packet header (301.i.l) comprising a transport error indicator (tei) (301.L1.2) and a packet identifier (PID) (301.L1.5) and a corresponding packet payload (301. i.2) including at least one section fragment (1001) and a section cyclic redundancy check (CRC) (151.3) for the section; and the de-encapsulator module (1401) is further configured to determine whether the at least one fragment is valid based on at least one of the tei and the PID of the packet header (301.L1) of the packet containing the fragment (1001) and whether a section header of the at least one section fragment is consistent according to a pre -determined consistency criterion.

20. The DVB-H system (1400) of claim 19, further comprising: a frame memory (1404) for storing the reconstructed section; and wherein, a valid section is defined as a fragment memory consisting entirely of valid fragments; and when a valid section having a consistent section header has been received, the de - encapsulator module (1401) is further configured to use the CRC to determine whether or not the section is valid, moves the section stored in the fragment memory (1100) to a frame memory (1404) for rendering therefrom and sets the erasure information (1102) of the fragment memory (1100) based on this determination; when a valid section has not been received, the de -encapsulator is further configured to, for each fragment (1106.i) of the fragment memory (1100), determine one of a location and length in the frame memory (1404) in which to place the fragment (1106.i) and ignore the fragment (1106.i) if a location cannot be reliably determined.

21. A method (1200-1300) for reconstructing a section (151) (152), comprising the steps of: prior to receiving a first section including a section header, setting a corrupt section indicator to 'off; receiving by a digital broadcast receiver (1403) the section (151) (152) in a sequence of at least one packet (301.i) that includes at least one section fragment; for each packet in sequence, performing the steps of- a. when a section header is received, setting the corrupt section header indicator to 'on' if the section header is not consistent based on a pre -determined section header consistency criteria, b. when the at least one packet is received correctly storing the fragment included therein in a corresponding column (1106.i) of a fragment memory (1100) and marking the column (1106.i) as containing a correctly received fragment, and b. when the at least one packet is received incorrectly, setting the corrupt section indicator to 'on' storing the fragment (10601) in a column (1106.i) along with its associated length (1103.i) variable or ignoring the column, based on a pre-determined fragment consistency criteria; if all fragments of the section have been marked as received correctly and the corrupt section header indicator is set to 'off, performing CRC processing (1217) to determine if the section is valid; and when all fragments of the section (151) (152) have been received, moving th e fragments (1106.i) from the fragment memory (1100) to a frame memory (1404).

22. The method (1200-1300) of claim 21, further comprising the step of determining an incorrectly received packet from a transport error indicator (30 Li.1.2) included in a packet header (301.i.l) of the at least one packet (30Li).

23. The method (800-900) of claim 22, further comprising the step of ignoring a packet if a packet header (301.i.l) of the at least one packet (30Li) includes a Packet Identifier (PID) (301.L5) of a pre-determined service type.

24. The method (1200-1300) of claim 21, further comprising the steps of: setting an associated erasure information (1102.i) of each column (1106.i) of the fragment memory (1100) to a predetermined value based on whether the column was at least one of not received correctly or has no associated address information, and if the corrupt section indicator is set to 'off, when all fragments of a section have been received and there are no missed fragments, performing the steps of- a. processing a CRC received in a payload of the sequence, and b. setting the erasure information (1102.i) for each column (1106.i) based on the result of the processed CRC.

25. The method (1200-1300) of claim 24, further comprising the steps of: maintaining each of a fragment pointer (FP) (1101) pointing at the next fragment column (1106.i) to receive a fragment, a shadow counter (SC) (1212 -1214) (1220) to track an expected value of a continuity counter of a packet header (301.i.l.8) CC that cycles fr om 0 to k to signal lost packets of a sequence, a discontinuity counter (DC), a missed fragment counter (K) and a floating fragment counter (F) (1208) (1209); initializing SC=CC for each section received; when the corrupt section indicator is 'off, enforcing the pre-determined consistency criteria of SC=CC (1206) (1207) for each received packet of the sequence of at least one packet (30Li); when the corrupt section indicator is 'on', enforcing the pre -determined consistency criterion of SC<=CC<=SC+Δ for a predetermined non-negative value of Δ (1223) (1230) for each received packet of the sequence of at least one packet (301.i); when a packet is one of received correctly and CC=SC or includes an un -correctable error and SC<=CC<=SC+Δ , performing the steps of- a. storing (1214-1215) (1228) (1236) the payload fragment at the column (1106.i) of the fragment memory (1100) pointed at by FP (1101), b. adjusting FP (1101) and SC to respectively point at the next column to receive a fragment and the value of CC expected in a next packet of the sequence. c. when a packet (301.i) includes an un-correctable error and CC≠SC, ignoring the packet.

26. The method (1200-1300) of claim 25, further comprising the step of determining an incorrectly received packet from a transport error indicator (30 Li.1.2) included in a packet header (301.i.l) of the at least one packet (30Li) and setting the corrupt section indicator to 'ON'.

27. The method (1200-1300) of claim 26, further comprising the step of ignoring a packet if a packet header (301.i.l) of the at least one packet (30Li) includes a Packet Identifier (PID) (301.L5) of a pre-determined service type.

28. The method (1200-1300) of claim 27, further comprising the step of prior to storing a correctly received fragment when CC≠ SC performing the steps of (1208-1213) (1225-1227, 1232-1235): advancing FP and K by ((CC-SC)(modulo 16); setting SC=CC; incrementing DC; recording a last missed fragment (LMF) as a column just prior to FP; and if a first missed fragment (FMF) is null, setting FMF=LMF.

29. The method (1200-1300) of claim 28, further comprising the step of wherein when all fragments (1001) of a sequence have been received, performing the steps of: when a fragment column (1106.i) has an associated length variable (1103.i) of 0 performing the substeps of setting an associated erasure information (1102.i) to a predetermined value and setting a counter F to a number of groups of floating fragments (DC- i); otherwise, if the corrupt section indicator is 'OFF', performing the steps of processing a CRC received in a payload of the sequence and setting the erasure information (1102.i) for each column based on the result of the CRC; and storing fragment memory (1106.i) in the frame memory (1404) in accordance with a pre-determined storage scheme based on the values of K and F.

30. The method (1200-1300) of claim 29, wherein the step of storing the fragment memory (1106.i) in the frame memory (1404) in accordance with the values of K and F further comprises the steps of: when K = O, storing the fragment memory at an address in the frame memory (1404) indicated by a table address (1105.2) received in a section header (151.1) and stored in a section header (705) of the fragment memory (700); when K ≠ 0 and at least one fragment of a current section and a next section (151) (152) is stored in the fragment memory (1100), using a table address of a section header of the next section to store the fragments (1106.i) of the fragment memory (1100) in the frame memory (1404); when K ≠ 0 and fragments (1106.i) from only one section (151) (152) are stored in the fragment memory (1100), performing the steps of determining the length of the missed fragments based on an adaptation field stuffing and using this length of each fragment (1106.i) of the fragment memory (1100) to consecutively store the fragment (1106.i) at the address in the frame memory (1404) indicated by a table address (1105.2) received in a section header (151.1) and stored in a section header (1105) of the fragment memory (1100).

31. The method (1200-1300) of claim 30, further comprising the step of when F ≠ 0 and the length of missed fragments is not fixed, erasing the missed (1107) (1109) and floating fragments (1108) from the fragment memory (1100) prior to storing the fragments (1106.i) of the fragment memory (1100) in the frame memory (1404).

32. A computer-readable medium containing computer-executable instructions structing a section by performing the steps recited in claim 30 (1200 -1300).