Enhanced error protection for packet-based service delivery in digital broadcasting systems

Field of the Invention

0001The present invention relates to a data packet structure defining a data packet of predetermined length for the transmission of a data stream in a digital audio broadcasting system, such as DAB or DRM. Further the present invention provides methods for transmitting and receiving packets using the data packet structure, as well as a corresponding transmitter and receiver. Moreover the present invention provides a digital broadcasting system using the data packet structure.

Technical Background

0002The Digital Audio Broadcasting (DAB) system has been developed by the European Eureka 147/DAB Project in close co-operation with the European Broadcasting Union (EBU) and has been finally standardized in ETSI EN 300 401: "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers" (available at http://www.etsi.org).

0003DAB provides high-quality sound and data as well as very robust reception quality for all types of receivers, e.g. home hi-fi, portable, personal and mobile terminals. Using COFDM (Coded Orthogonal Frequency Division Multiplex) the transmission medium is capable of delivering program services to more listeners and more robust, than is possible with the existing VHF/FM sound broadcasting.

0004The DAB transmission signal is built around a time-multiplex comprising three channels: a synchronization channel 102, a fast information channel (FIC) 103 and a main service channel (MSC) 104, as shown in Fig. 1. Together, these three channels form a so-called transmission frame 101.

Synchronization channel

0005The synchronization channel 102 incorporates basic receiver control mechanisms, such as automatic frequency control (AFC), automatic gain control (AGC) and a phase reference. It may also be used to carry encoded transmitter identification information.

Fast Information Channel

0006The fast information channel (FIC) 103 has a limited capacity for data transmissions but may be capable of supplying information to a receiver faster than the main service channel allows. This is because data on the FIC is not subjected to time-interleaving in the COFDM coding process as the data sent through main service channel (MSC) 104. Fig. 8 illustrates an exemplary conceptual DAB emission block diagram.

0007The degree of protection of FIC data may be given by convolutional coding at a permanently fixed code rate of about 1/3 because otherwise it would require another level of signaling, with even faster response and even better protection, to signal other possibilities. In order to achieve acceptable error performance, FIC data is repeated regularly. The main application of the FIC 103 is the provision of the multiplex configuration information (MCI) to the receivers. The multiplex configuration information defines the multiplex structure of data on the MSC 104. Furthermore the FIC 103 comprises service information (SI). Other data service components may also be transmitted in the FIC.

0008It is further possible to change the multiplex configuration, while maintaining the continuity of services. In this case, two sets of multiplex configuration information may be transmitted in parallel in the FIC (current/next configuration), which temporarily reduces the remaining capacity to transport service information and/or data service components.

Main service channel

0009The main service channel (MSC) 104 is the largest portion of the DAB ensemble carrying the major portion of the transmission data.

0010An ensemble may be understood as the transmitted signal comprising a set of regularly and closely spaced orthogonal carriers. The ensemble may be the entity which is received and processed, and may contain program and data services.

0011The main service channel 104 may e.g. be divided into sub-channels to provide different audio service components for broadcasting. In DAB terminology, services are considered to be either (audio) program services or data services and are supplied by a service provider.

0012Each sub-channel may also carry program associated data (PAD) when carrying DAB audio frames. PAD may be audio-synchronous information and its contents may be intimately related to the audio. The PAD bytes in successive audio frames may constitute the PAD channel. PAD may e.g. provide Dynamic Range Control (DRC) allowing the receiver to adapt the dynamic range of an audio signal to listening in a noisy environment, a Music/Speech indication, which indicates whether the transmitted sound comprises music or speech, and/or a command channel to convey, synchronously to the music, special commands to the decoder. Program related text and/or a Universal Product Code/European Article Number, when transmitting by digital carriers of prerecorded software.

0013The MSC 104 may have a gross capacity of 2.3 Mbit/s. Depending on the convolution code rates this leads to net bit rates between 0.6 and 1.8 Mbit/s. Data samples of the source signal are spread over sixteen logical frame periods (time interleaving). The transmitted signal consists of consecutive COFDM (Coded Orthogonal Frequency Division Multiplex) symbols generated by means of D-QPSK (Differential Quadrature Phase Shift Keying) and frequency interleaving.

DAB Transport Mechanisms

0014DAB provides basically four Transport Mechanisms for content. The content data may be transmitted as MSC Stream Audio, MSC Stream Data, in a Fast Information Data Channel (FIDC) or as MSC Packet Data (packet mode).

0015Depending on the reception conditions and the applied convolutional error control code rate a part of the received DAB data packets - when operated in packet mode - may be damaged and must be discarded.

0016In order to reduce the number of discarded data, additional error control codes for use in the DAB packet mode (MSC Packet Data) have been proposed. For example, Sostava et al., proposed in "Investigations on the Bit Error Performance for Video over DAB" (IEEE Transactions on Broadcasting, Vol. 44, No. 4, December 1998) to introduce additional error control coding to a whole DAB sub-channel by using an additional packet channel using a particular packet address and using a particular Reed-Solomon scheme (204, 188) for coding the whole sub-channel which is used for transmitting a MPEG-2 transport stream via DVB-H. However this scheme provides only little flexibility as only a complete sub-channel may be provided with additional protection and the proposed method is tied the Reed-Solomon coding only. Also the backwards compatibility is rather doubtful as conventional receivers will miss the part of the MCI describing a service component belonging to the packet address carrying the error control code fields.

0017The DAB network is typically designed for Bit Error Rates of 10^-4 at the receiver after convolutional decoding. For some user applications, e.g. video applications require lower Bit Error Rates (BER) in the order of 10^-8 to 10^-10 for widely undisturbed presentation.

Summary of the Invention

0018The object of the present invention is to increase the number of data packets of which undamaged data can be derived under identical reception condition.

0019The object is solved by the subject matter of the independent claims. Advantageous embodiments of the present invention are subject matters to the dependent claims.

0020One aspect of the present invention is related to the introduction of additional error control coding for a packet based digital audio broadcasting transport mechanism. The proposed solution provides a fully back-wards compatible way for solving the object above, i.e. does not require any changes to conventional receivers.

0021An embodiment of the present invention relates to a data packet structure defining a data packet of predetermined length for the transmission of a data stream in a digital audio broadcasting system. The data packet structure may comprise a packet header enabling the identification of the data stream and the length of application data of the data stream in a packet data field as well as the packet data field comprising a field with the data of the data stream. Further, the packet data field may comprise an error control code field generated based on at least a part of the packet data field section and at least a part of the packet header.

0022According to a further embodiment of the invention, a data stream may for example be a sequence of one or more packets with the same packet address in the same sub-channel comprising application data belonging to the same application instance (e.g. slide show). The data stream may be provided as a service component in the transmission. A service component may relate to a several services. E.g. a content provider may have a single web page with information related to several broadcast programs of the content provider. In this example the web page may be understood as a single service component for several services, i.e. broadcast programs.

0023In a further embodiment of the present invention the information in the data packet structure's error control code field may be generated using a Reed-Solomon code or a turbo code or another error control code. Alternatively the error control code field may comprise CRC data.

0024Another embodiment relates to a data packet structure in which the packet data field further comprises a padding section for providing padding bits to match the data packet length to the predetermined packet length.

0025In still another embodiment of the invention related to the data packet structure, the structure further comprises a CRC field calculated based on the packer header and the packet data field.

0026Moreover, the present invention is related to a method for transmitting a packet-based data stream in a digital audio broadcasting system. The method may comprise the steps of generating a packet header enabling the identification of the data stream and identifying the length of application data of the data stream in a packet data field, generating the packet data field comprising a field with the application data and an error control code field, generating the error control code field based on at least a part of the packet data field section and at least a part of the packet header section, and concatenating at least the packet header and the packet data field to form a data packet. Further, a transmission frame comprising the formed data packet may be generated and transmitted.

0027In another embodiment of the invention information of the error control code field is generated using at least one error control code of at least one particular error control code scheme.

0028As an additional option, the method according to this embodiment proposes to signal the information on the length of the error control code field, the at least one used error control code and the corresponding at least one error control code scheme within an information data stream being part of the transmission frame.

0029According to another embodiment of the present invention the formed data packet is comprised within a main service channel of the transmission frame.

0030The method according to a further embodiment of the invention comprises the step of using application information carried in the information data stream for associating the information on the length of the error control code field, the at least one used error control code and the corresponding at least one error control code scheme with the data stream carrying the application data for a corresponding application instance.

0031According to a further embodiment the present invention provides a method for receiving a packet-based data stream in a digital audio broadcasting system. The method may comprise the steps of receiving a transmission signal comprising the data stream, extracting at least one transmission frame comprising the data stream from the transmission signal, extracting a main service channel from the transmission frame, and extracting from the main service channel at least one data packet used to transmit the data stream, wherein the at least one data packet comprises a packet header and a packet data field comprising application data of the data stream and an error control code field. Further the data integrity of at least a part of the packet header and at least a part of packet data field may be verified using information in the error control code field.

0032The method according to a further embodiment may also comprise the steps of extracting an information data stream from the transmission frame and extracting from the information data stream information on the at least one applied error control code and an at least one corresponding error control code scheme used to generate the information in the error control code field.

0033As an additional option this embodiment of the invention further proposes to extract information on the length of the error control code field when extracting the information.

0034According to another embodiment of the invention the information in the error control code field protects at least a part of the data packets used to transmit the application data for an application instance.

0035The method according to another embodiment may further comprise correcting at least a part of the packet data field and/or at least a part of the packet header using the information in the error control code field.

0036A further embodiment of the present invention suggests to extract application information from the information data stream enabling the identification of data packets belonging to the data stream and being associated to the information on the at least one error control code and the corresponding at least one error control code scheme based on the application information.

0037Another embodiment of the present invention provides transmitter for transmitting a packet-based data stream in a digital audio broadcasting system. The transmitter may comprise means for generating a packet header enabling the identification of the data stream and the length of application data in a packet data field. This means may be adapted to generate a packet data field comprising a field with said application data of the data stream and an error control code field, to generate the error control code field based on at least a part of the packet data field and/or at least a part of the packet header and to concatenate at least the packet header and the packet data field to form a data packet. Further, the transmitter may comprise multiplexing means for generating a transmission frame comprising the formed data packet, and a transmission means for transmitting the transmission frame.

0038Moreover, another embodiment of the present invention is related to a transmitter in a digital audio broadcasting system transmitting data to a receiver, wherein the transmitter comprises means adapted to perform the transmission method described above.

0039A further embodiment of the present invention provides a receiver for receiving a packet-based data stream in a digital audio broadcasting system. The receiver may comprise a reception means for receiving a transmission signal comprising said data stream, and processing means for extracting at least one transmission frame comprising said data stream from the transmission signal. The processing means may be adapted to extract a main service channel from the transmission frame, to extract from the main service channel at least one data packet used to transmit said data stream, wherein the at least one data packet comprises a packet header and a packet data field comprising application data of said data stream and an error control code field and to verifying the data integrity of at least a part of the packet header and/or at least a part of packet data field using information in the error control code field.

0040An embodiment of the present invention provides a receiver in a digital audio broadcasting system receiving data from a transmitter, wherein the receiver comprises means adapted to perform the reception method outlined above.

0041Further, a digital audio broadcasting system for transmitting data from a transmitter to a receiver using one of the data packet structures described above is provided in another embodiment of the present invention. According to a further embodiment the digital audio broadcasting system may be adapted to use one of the above mentioned receivers and/or transmitters.

Brief description of the Figures

0042In the following the present invention is described in more detail in reference to the attached figures and drawings. Similar or corresponding details in the figures are marked with the same reference numerals. <dl id="dl0001"><dt><b>Fig. 1</b></dt><dd>shows an exemplary overview of the structure of a transmission frame in DAB,</dd><dt><b>Fig. 2</b></dt><dd>shows an exemplary overview of the structure of a fast information group (FIG) in DAB,</dd><dt><b>Fig. 3</b></dt><dd>shows a DAB data packet structure according to an embodiment of the present invention,</dd><dt><b>Fig. 4 &amp; 5</b></dt><dd>show a flow chart of an exemplary transmission method of at least one data packet of a packet-based data stream within a transmission frame according to an embodiment of the present invention,</dd><dt><b>Fig. 6</b></dt><dd>shows a flow chart of an exemplary reception method of at least one data packet of a packet-based data stream within a transmission frame according to an embodiment of the present invention,</dd><dt><b>Fig. 7</b></dt><dd>shows a flow chart of another exemplary reception method of at least one data packet of a packet-based data stream within a transmission frame according to an embodiment of the present invention,</dd><dt><b>Fig. 8</b></dt><dd>shows a conceptual DAB emission block diagram according to an embodiment of the present invention,</dd><dt><b>Fig. 9</b></dt><dd>shows an exemplary delivery mechanism of service component data from a content provider via a broadcast station to a terminal according to an embodiment of the present invention,</dd><dt><b>Fig. 10</b></dt><dd>shows a DRM data packet structure according to an embodiment of the present invention,</dd><dt><b>Fig. 11</b></dt><dd>shows a conceptual DRM emission block diagram according to an embodiment of the present invention, and</dd><dt><b>Fig. 12</b></dt><dd>shows a conventional data packet structure of the DAB standard.</dd></dl>

Detailed Description of the Invention

0043On aspect of the present invention is to enable the widely undisturbed reception of data under conditions which lead to unacceptable disturbance when only applying the convolutional error control coding, e.g. being part of the DAB Standard ETSI EN 300 401. For this purpose the available data capacity within a data packet may be split such that a part of its capacity is used for application delivery whereas the remaining part may be used for the error control code field. An exemplary new resulting data packet structure is shown in Fig. 3. A backwards-compatible implementation of this embodiment of the present invention is possible, i.e. existing DAB receivers not equipped for processing the error control code field, remain fully operational.

0044The error control code used in the present invention is the so called forward-error-correction coding to correct even without a feedback channel as for example described by Alister Burr in "Modulation and Coding for Wireless Communications", chapter 5, Prentice Hall, 2001. The error control code may comprise additional redundancy allowing the detection and correction of possible errors in the data packet, in contrast to the packet CRC 303, 1003 (see Fig. 3 and 10) which only allow the detection but not the correction of errors. An example for such codes are cyclic block codes such as BCH-, Reed-Solomon (RS)-, or turbo codes. The error control code scheme may describe the total length of the packet, the length of the useful data and the mother code. An example for such a scheme is the RS(204,188) may describe a shortened Reed-Solomon Code RS(256,188) with a packet length of 204 bytes and 188 bytes of useful data.

0045Next, the data packet structures shown in Fig. 12 and Fig. 3 will be described in greater detail and the differences between the two structures will be outlined. Both, the conventional data packet structure of Fig. 12 and the data packet structure of Fig. 3, illustrating an embodiment of the present invention, comprise a packet header 301,1201, a packet data field 302,1202 and a packet CRC field 303,1203.

0046The packet header 301,1201 may comprise a packet length field 304,1204 indicating the total data packet length. The packet length may for example be expressed in terms bytes. The packet length may be chosen among a predetermined number of differently but fixed sized data packet structures, wherein the packet header 301,1201 and the packet CRC 303,1203 is of constant length but the length of the packet data field varies.

0047If for example four data packet structures of different data packet lengths exist, the packet length field may use two bits to differentiate between the four options.

0048The packet header's continuity index 305,1205 may represent a counter incremented by one for each successive packet in a series having the same address 307,1207. It may provide the link between successive data packets, carrying the same service component, i.e. data stream, regardless of the packet length. When for example implemented as a modulo-4 counter two bits are sufficient to encode this field.

0049The first/last flags 306,1206 may be used to identify particular data packets which form a succession of data packets which carry data groups of the same service component. For service components that are transported without data groups, the flags may be set to 0. When data groups are used to transport the service component, the first/last flags 306 may for example indicate an intermediate packet of a series if set to 00, the last data packet of a series if set to 01, the first data packet of a series if set to 10 and the only data packet if set to 11.

0050The address field 307,1207 may identify data packets carrying a particular service component within a sub-channel. To enable the provision of multiple service components within a single sub-channel 10 bits may be used to encode this field. When reserving the address 0 for padding packets up to 1,023 service components may be carried simultaneously in a sub-channel.

0051The command field 308,1208 of the packet header 301,1201 may indicate whether the packet is used for general data or for special commands. Finally, according to this embodiment of the present invention the packet header 301,1201 comprises a useful data length field 309,1209 which may be coded as an unsigned binary number to represent the length in bytes of the associated useful data field 310,1210 in the subsequent packet data field 302,1202.

0052Packet data field 302,1202 may comprise the useful data field 310,1210 and a padding field 312,1212. The useful data field 310,1210 may contain the useful service component data, i.e. the actual payload data of the data stream transmitted within data packet. Further, the both structure may comprise a padding field comprising the bytes required to complete the packet data field to match the total packet length the value given by the packet length field 304,1204.

0053In contrast to the conventional packet structure shown in Fig. 12 the proposed packet structure of Fig. 3 according to this embodiment of the present invention further comprises an error control code field which provides additional error correcting capabilities to the receiver to correct transmission errors within the data packet as will be outlined in more detail below.

0054The padding field 312 may only be present if the length of the packet header 301, the useful data field 310, the error control code field 311 and the packet CRC data 303 is smaller than the desired predetermined packet length. In this situation the padding field 312 may be included in order to match the desired packet length.

0055Finally, in both packet structures the packet CRC 303,1203 may be implemented as a 16-bit CRC word calculated on the packet header 301,1201 and the packet data field 302,1202. The generation of the packet CRC 303,1203 may for example be based on a polynomial proposed in the ITU-T Recommendation X.25.

0056Each data packet carries 2 bytes of CRC data 303,1203, which allows determining, if the data packet has been damaged or not. If it is damaged, it would have to be completely discarded in a conventional digital audio broadcasting system, since neither the packet address field 307,1207 nor the data packet length 304,1204 may be uniquely identified anymore. This may be due to the position(s) of the erroneous bit(s) within the data packet is/are unknown.

0057Therefore one embodiment of the present invention proposes to apply improved protection to data packets by applying the additional error control code to the data packet or at least to those parts necessary for extracting an undamaged data payload 310 for the desired user application (see error control code field 311 of the data field 302 in Fig. 3). When correcting parts of an erroneous data packet it may be possible to extract application data from a data packet for which the CRC check failed. Hence, the payload may be derived from more received data packets than it would be feasible in the absence of the additional error control coding.

0058Also existing digital audio broadcasting receivers not aware of the newly introduced additional error control coding may be able to derive the data payload 310,1210 for the desired user application in the case the CRC check succeeds (full backwards compatibility).

0059In another embodiment of the present invention the presence of the additional error control code information within the packet data field 302,1202 of data packets of a particular packet address does not need to be signaled to the receiver, if a predetermined error correction coding is applied an the error control code field is assumed to be of constant length.

0060However, to allow for a more flexible error control coding, a further advantageous embodiment of the present invention proposes to signal the error control code used (e.g. Reed Solomon code, turbo code) and its corresponding error control code scheme (e.g. Reed-Solomon (204, 188)) as well as the length of the error control code field 311 in an information data stream to the receiver. For example a Fast Information Group (FIG) of the FIC may be used to signal the error control coding parameters.

0061In another embodiment of the present invention the additional error control code may be applied to the data of the packet header 301 and the application data within the useful data field 309. Optionally only parts of the header 301, e.g. the packet length field 304, the address field 307 and the useful data length field 309 may be protected by the error control code. Additionally also the padding field 312 may be included.

0062Next, a conceptional DAB mission block diagram according to an embodiment of the present invention is outlined with reference to Fig. 8. For example a content provider 901 as shown in Fig. 9 provides a service component data and related service information. The service component data, which may for example multi-media data stream, is input into the packet builder &amp; error control coder 814.

0063The packet builder &amp; error control coder 814 collects the different input streams and maps them into data packets. Hence, several service data components of different content providers may be delivered to packet builder &amp; error control coder 814. Further, the packet builder &amp; error control coder 814 provides the selection of the appropriate data packet length and error control coding of at least parts of the data packets to generate the information of the error control code field comprised in the data packet. For example, the data packet structure of Fig. 3 or Fig. 10 may be used.

0064The packet builder &amp; error control coder 814 may further assign corresponding packet addresses 307 (see Fig. 3) to the service component data of a single user application instance. Hence, by using different data packet addresses 307, it is possible to distinguish between different user application instances and their related service component data.

0065The packet multiplex assembler 801 fills an available sub-channel with the data encapsulated in the error-control-coded data packets for the different user application instances making use of packet mode transmission on the sub-channel.

0066Further, the packet multiplex assembler 801 may apply different strategies for filling the sub-channel. The application data of the different user application instances may for example be sequentially provided or packets may be provided in parallel for the different user application instances using different packet addresses 307. Further options for packet sequence strategies may be the length and duration of the data bursts in the number of packets of the same address 307 sent in an immediate sequence. In order to support the most proper transmission strategy the packet multiplex assembler 801 may be arranged to prioritize one or more user application instances in their completely or individually file by file.

0067The packet multiplex assembler 801 output the packets mode data to an energy dispersal scrambler 802. The energy dispersal scrambler 802 provides a deterministic selective complementing of bits in logical frame intended to reduce the possibility that systematic patterns result in unwanted regularity in the transmitted signal. The scrambled packet mode data is convolutional encoded in convolutional encoder 803 and is interleaved in time interleaver 804. The interleaved data is then multiplexed in the main service multiplexer 808 with data of the upper branch shown in Fig. 8 which will be described next.

0068Digital audio broadcasting may be capable of delivering various data types from the transmitter to the receiver. The upper branch in Fig. 8 is intended to summarize the other possible services that may be carried by DAB. For example, also service information, DAB audio frame and stream mode data may be scrambled in energy dispersal scrambler 805, corresponding in its functionality to energy dispersal scrambler 802. The scrambled data is encoded in convolutional encoder 806 and the encoded data is interleaved in time interleaver 807. The time interleaved data is then multiplexed with the scrambled, encoded and interleaved packet mode data in main service multiplexer 808 to form common interleaved frames (CIFs).

0069The CIFs are the serial digital output from the main service multiplexer 808 which is contained in the main service channel part of the transmission frame. Taking the transmission system as an example, the common interleaved frame is common to all transmission modes and comprises 55 296 bits i.e. 864 capacity units.

0070Next, the lower branch shown in Fig. 8 will be described in more detail. A second possibility to provide service information i.e. auxiliary information about services such as service label and program type codes to the receiver the service information may be closer in the lower branch 809, 810, 811 and 812 of Fig. 8. Also the service information related to the service component data inputted to packet multiplex assembler 801 is provided to the service information assembler 809. The service information assembler 809 assembles the service information at its input to the Fast Information Groups (FIG) <u>which are output</u> to the fast information block assembler 810. The fast information block assembler 810 collects the different FIGs provided in the fast information channel (FIC) of the digital audio broadcasting system. Using the example of DAB service information multiplex control information (MCI) as well as the fast information data channel (FIDC) may provide input to the fast information block assembler 810.

0071The multiplex configuration information (MCI) may be information defining the configuration of the multiplex in the main service channel. The multiplex configuration information may contain the current details about the services, service components and sub-channel and the linking between these objects in the main service channel. In case of an imminent reconfiguration the forthcoming details about services, service components and sub-channels and the linking between these objects may additionally be provided in the multiplex configuration information.

0072The MCI may be carried in the fast information channel in order that a receiver may interpret this information in advance of the service components stored in the MSC. It may also include identification of the ensemble and a date and a time marker.

0073The fast information block assembler 810 output is a concatenation of fast information blocks (FIBs), as for example shown in Fig. 1. The FIBs may be scrambled in energy dispersal scrambler 811 and may be convolutional encoded in encoder 812 to form the so-called fast information channel (FIC). The fast information channel and the common interleaved frame may be a multiplier in the FIC &amp; CIFs multiplexer 813 to output a pre-transmission frame. The term "pre-transmission frame" is used in this context in order to indicate that a complete transmission frame further comprises the synchronization channel, as for example shown in the transmission frame structure of Fig. 1.

0074Taking the example of DAB, the provision of error control code field information (e.g. error control code used and the corresponding error control code scheme, error control code field length) related to the service component data delivered in packet mode and being protected by an additional error control code field to the receiver will be outlined in reference to Figs. 1 and 2 in the following sections.

0075The error control code field information related to the service component data, for example the error control code and its corresponding error control code scheme use to generate the error control code field data as well as the length of the error control field within the packet structure shown in Fig. 3 may be signaled to the receiver, if these parameters are not predefined i.e. may be flexible. This information may be carried in the forward information channel or more generally in another information data stream to/from the transmitter to the receiver.

0076Fig. 1 illustrates a transmission frame 101 comprising the synchronization channel 102, the fast information channel (FIC) 103 and the main service channel (MSC) 104. The FIC 103 comprises a concatenation of so-called fast information blocks (FIBs) 105, 106. The main service channel 104 is made up of several common interleaved frames (CIFs) 107, 108.

0077Each fast information block 105, 106 comprises an FIB data field 109 as well as a CRC field 110. The FIB data field 109 is formed by a concatenation of fast information groups (FIGs) 111, 112, 113 and includes an end marker 114 and padding field 115 at its end. The padding field 115 may be used in case the FIB data field 109 has to be matched to a predetermined length. Each fast information group 111, 112, 113 comprises an FIG header 118 and an FIG data field 119. The FIG header 118 indicates the FIG type 116 as well as the length of data in the FIG data field (FIG data field length 117).

0078In an exemplary embodiment of the present invention, the service information related to the service component data may be signaled in an "FIG type 0 extension 13" format. This format is shown in more detail in Fig. 2. It should be noted that it is also possible to define a new FIG type for the provision of the error control code field information related to the component service data provided in packet mode and being protected by an additional error control code field data within each data packet.

0079The FIG header 118 comprises the FIG type field 116 which would be sent to zero in the present example. The FIG data field 119 further comprises the C/N flag 201 which may indicate the current version of a multiplex configuration provided in the type zero field, when providing a data base the state of start of the database or the continuation of a database or in case a chain to the database needs to be signaled the current next flag may be used to signal a change event. The OE field 202 may indicate whether the information provided within the fast information group 111, 112, 113 is related to this ensemble or another.

0080The P/D flag 203 is intended to indicate the length of the service identifier 209 which may for example 16 bits or 32 bits long. The service identifier 209 is for example included in the user application information subfield 206, 207, 208 which will be described in the following sections.

0081The extension field 204 of the FIG data field 119 indicates the extension used for the type 0 field. In the present example, the extension may be equal to 13. The type 0 field comprises a concatenation of user application information subfield 206, 207, 208 (in case information of several user applications have to be signaled) in the present example.

0082Each user application information subfield 206, 207, 208 comprises a service identifier 209, to identify the service the user application information relate to, and a service component identifier with the service 210 identifying the service component within the service to which the user application information subfield 206, 207, 208 relates.

0083The combination of the service identifier 209 and the service component identifier within the service 210 provide a globally valid identifier for a particular service component. Hence, by the combination of these two fields, the data stream provided in packet mode to the receiver as a service component may be explicitly identified.

0084Following the two identifiers 209, 210, the number of user applications field 211 may indicate the number of applications contained in the subsequent list of user application data 212, 213, 214 (user application no. 1, user application no. i, etc). Each user application field 212, 213, 214 comprises a user application type 215 which identifies the user application to be used to decode the data in the channel identified by the service identifier 209 and the service component identifier within the service 210, as well as a user application data length 216 indicating the length of the user application data field 217. Together, the user application type field 215, the user application data length field 216 and the user application data field 217 form the so-called user application information 218.

0085In the user application data field, the error control code field information related to the service component data or more specifically to the error control code and its corresponding error control code scheme used to generate the generate in the error control field of the data packets providing the service component data as well as the lengths of this error control code field may be indicated.

0086By using a different bit combination of an appropriate length, the receiver may distinguish whether for example a Reed-Solomon code or a turbo-code has been used to generate the data of the error control code field. Another bit combination may indicate the error control code scheme used and another field within the user application data may inform the receiver on the length of the error control field in the data packet providing the respective service component data.

0087The service identifier 209 and the service component identifier within the service 210 mentioned above may identify the service component carrying the user application. The packet address and the sub-channel identifier may be derived from the service component information carried in the fast information channel. The position of the packet in the transmission frame may be derived from the packet address and the sub-channel identifier.

0088In reference to Figures 4 and 5, a flow-chart of an exemplary transmission method of at least one data packet of a packet based data stream within a transmission frame according to an embodiment of the present invention will be described in more detail.

0089In a first step 401, the transmitter generates a packet header as shown for example in Fig. 3. Next, an error control code and its corresponding error controlled code scheme are used to generate 402 an error control code field by applying error control coding to at least a part of the application data of the service component comprised in the data packet and/or at least a part of the packet header. It may be possible to protect only part of the data of the service component as well as the most relevant part in the packet header. The error control field and its length result from this generation process.

0090The service component data as well as the error control field data may be used to generate a packet data field in step 403. An example of a packet data field is shown in Fig. 3.

0091Next, the packet header and the generated packet field may be concatenated in step 404 and the appropriate data packet length from a number of different predetermined data packet lengths may be chosen in step 405. The present embodiment of the invention may use data packets of different but fixed lengths such that each data packet has a given packet length which has to be filed with data prior to transmission.

0092Further, the transmitter may determine whether the concatenation of the packet header and the packet data field would result in the determined given packet length when also included a CRC field at its end. If there are not enough bits to fill the complete data packet by including the packet header, the packet data field in the CRC field, the transmitter may add padding bits to the packet data field to match the data packet length to the appropriate size in step 407.

0093Once the appropriate length of the packet header and the packet data field has been obtained, a CRC data for the packet header and the packet data field may be calculated 408. In the subsequent step 409 a data packet may be formed by concatenating the packet header, the packet data field and the generated CRC data.

0094In case, the error control code in its corresponding error control scheme as well as the error control code field length is variable, those parameters are used to generate the necessary data to fill user application information in step 501. The definition of the user application information has been outlined above in reference to Fig. 2.

0095Further, the data packet may be used by a generation process 502 of the main service channel (MSC). In this step, the different services are multiplied to CIFs forming the main service channel as illustrated in Fig. 8. The input data packet to block 502 is intended to illustrate that in the generation process of the main service channel also the data packet generated in step 409 is included into the main service channel.

0096The user application information may be included in the fast information channel in step 503 or more generally to an information data stream. In this step, the fast information channel (FIC) is generated. The FIC may among other data (e.g. FIDC, MCI) comprise the relevant signaling of the parameters related to the generation of the error control code field data (see step 402) for the particular service component, data of which is transmitted in the generated data packet (see step 409) in the main service channel (MSC).

0097As also illustrated in Fig. 8, the main service channel i.e. the concatenation of CIFs as well as the FIC is multiplexed to generate a pre-transmission frame. Next, the symbols of the pre-transmission frame i.e. the fast information channel and the main service channel are generated in step 505. To these symbols, the synchronization channel symbols are added in step 506 to form the symbols of the transmission frame. Next, in step 507 the OFDM signal of the transmission frame symbol is generated and in step 508 the OFDM signal is transmitted to the receiver.

0098It should be noted that in a further embodiment of the present invention, steps 401 to 409 may be performed in the packet builder &amp; error control coder 814 shown in Fig. 8. The step 501 generating the user application information may be performed by the service information assembler 809. The generation of the fast information channel may be performed by fast information block assembler 810 and the subsequent scrambling and coding by entities 811 and 812. The main service channel may be provided by multiplexing the different services in the main service multiplexer 808.

0099Next, different embodiments of a reception process for receiving data packet of a configuration as for example as illustrated in Fig. 3 will be described in the following text passages.

0100Fig. 6 shows a flow chart of an exemplary reception method of at least one data packet of a packet-based data stream within a transmission frame according to an embodiment of the present invention. Upon receiving the transmission data from a broadcast station in step 601, the transmission data is processed and the fast information channel may be extracted therefrom in step 602. To be able to receive a particular service component comprised in data packets provided with an additional error control code field as illustrated in Fig. 3, the information on the used error control code, the corresponding error control code scheme as well as the length of the error control code field may be extracted from the fast information channel in step 603. Further, the data packet's position within the main service channel may also be extracted from the fast information channel in step 604.

0101Upon having obtained this information, the main service channel may be extracted from the transmission data next in step 605 and using the data packet's position and the extracted main service channel, the data packet for carrying the respective service component and providing an additional error control code field may be extracted from the main service channel in step 606.

0102Having obtained the data packet from the main service channel, the packet CRC may be extracted therefrom in step 607. The CRC data may be used in step 608 to determine, whether the data packet has been forged during transmission. In case the data packet's integrity is verified, the flow advances to block 611, where the intact data packet is provided to a further processing instance, e.g. a user application.

0103In case the integrity of the data packet has not been verified in the CRC check, the information on the error control code and scheme as well as the error control code field length may be used to extract 609 the error control field data from the data packet. Using the extracted data transmission errors in the received data packet may be corrected in step 610. Next, the data integrity of the corrected data packet may be checked again in step 608, which should result in the verification of the data packet's integrity such that the flow proceeds to step 611. In the unlikely case, the data packet has been heavily damaged such that the additional error control coding may not provide sufficient redundancy to correct all errors for a successful recovery of the address field data and useful data file data, the data packet may be discarded.

0104Fig. 7 shows a flow chart of another exemplary reception method of at least one data packet of a packet-based data stream within a transmission frame according to an embodiment of the present invention. Method steps in Fig. 7 that correspond to method steps in Fig. 6 have been assigned the same reference numerals and their detailed description will be omitted. The reception method proposed in Fig. 7 differs from the one known from Fig. 6 in that it does not rely on the CRC data in the data packet at all but only used the data of the error control code field to verify the integrity of the received data packet.

0105After having obtained the data packet from the MSC in step 606, the error control code field data may be extracted 701 from the data packet using the information related to the related field. Next the error control code field data may be used to determine 702 whether the data packet has been corrupted during transmission or not. If not, the data packet may be forwarded for further processing to another instance, e.g. a user application in step 611.

0106If the data packet is corrupted, the error control code field data may be used to correct 703 the errors in the data packet and if the corrected data packet is found to be intact in step 702 same may be forwarded to a further processing instance in step 611. In the unlikely case, the data packet has been heavily damaged such that the additional error control coding may not provide sufficient redundancy to correct all errors for a successful recovery of the address field data and useful data file data, the data packet may be discarded.

0107It should be noted that the exemplary embodiments of the present invention provided with respect to Figures 4, 5, 6 and 7 assume that there is a flexible use of error control code and error control code schemes as well as a flexible error control field code length provided.

0108However, as already indicated before, it may be also possible to use a predetermined error control code and corresponding error control code scheme as well as a predetermined error control code field length. For example the error control code and its scheme may be predefined based on the user application for which data is provided to the receiver using the proposed improved data packet format. In this case, no additional signaling of an information data stream through the fast information channel (i.e. no signaling of the error control code information related to the service component data) may be required since the transmitter may be well aware of the presence of the error control code field within the data packet as well as the error control code and error control scheme used to generate the error control code field data of a specific length.

0109Hence, in the exemplary embodiments of the present invention illustrated in Figures 4, 5, 6 and 7, the steps relating to the generation of the user application information as well as their extraction from the fast information channel as well as steps related to the use of these information for appropriately obtaining the content of the error control code field when receiving transmission data may be obsolete.

0110Further, it should be also noted that also part of the involved parameters for generating an error control code field may be predetermined while another part may be flexible. For example, different error control codes and schemes may be used to generate the data of the error control field, while the error control field is of predetermined length. Hence, in this embodiment of the present invention, only the error control code and its corresponding scheme may be signaled to the receiver.

0111For the transport of sensitive content to portable and mobile devices DAB may be more efficient than the recently developed DVB-H System due to an independent convolutional coding for each sub-channel, and due to processing just the relevant part of the multiplex instead of processing of the whole multiplex requires lower receiver performance ("advanced time slicing"). Further, DAB is also applicable to mobile environments up to speeds of 400 km/h without any degradation of the data rate. Further, a differential modulation (DQPSK) requires as in DAB lower Receiver performance than coherent channel estimation for DVB-T, DVB-H. DAB also allows for unlimited size of Single Frequency Networks (SFN) while DVB-H SFN limits the size of the SFN in the order of 200 km.

0112Further, according to another embodiment of the present invention the principles and ideas underlying the present invention may also be applied to the broadcasting system DRM (Digital Radio Mondiale). The following sections will briefly outline the conceptual transmission of data in DRM (see Fig. 11) as well as present a new DRM data packet structure (see Fig. 10).

0113The conventional Digital Radio Mondiale (DRM) uses the similar transport mechanism to deliver content as a conventional DAB system. The DRM system is designed to be used at any frequency below 30 MHz, i.e. within the long wave, medium wave and short wave broadcasting bands, with variable channelization constraints and propagation conditions throughout these bands.

0114Figure 11 shows a novel conceptual DRM emission block diagram according to an embodiment of the present invention, which describes the general flow of different classes of information (audio, data, etc.) and does not differentiate between different services that may be conveyed within one or more classes of information.

0115The source encoder 1101 and pre-coders 1108, 1111 ensure the adaptation of the input streams onto an appropriate digital transmission format. For the case of audio source encoding, this functionality includes audio compression techniques. The output of the source encoder(s) 1101 and the data stream pre-coder 1102, 1108, 1111 may comprise two parts requiring different levels of protection within the subsequent channel encoder. All services have to use the same two levels of protection.

0116The pre-coder &amp; error control coder 1102 ensure the adaptation of the input streams onto an appropriate digital transmission format, inter alia mapping the data streams into data packets. According to an embodiment of the present invention, the pre-coder &amp; error control coder 1102 further performs an error control coding of the at least a part of the application data and/or the generated packet headers and forms data packets in a structure as for example depicted in Fig. 10. Hence, the pre-coder &amp; error control coder 1102 provides the information of the error control code field and inserts same into the data packets for each data stream.

0117The multiplexer 1103 may combine the protection levels of all data and audio services. The energy dispersal 1104, 1109, 1112 provides a deterministic selective complementing of bits in order to reduce the possibility that systematic patterns result in unwanted regularity in the transmitted signal.

0118The channel encoder 1105, 1110, 1113 adds redundant information as a means for quasi error-free transmission and defines the mapping of the digital encoded information onto QAM cells.

0119Cell interleaving 1106 spreads consecutive QAM cells onto a sequence of cells quasi-randomly separated in time and frequency, in order to provide robust transmission in time-frequency dispersive channels. The pilot generator provides means to derive channel state information in the receiver, allowing for a coherent demodulation of the signal.

0120The OFDM cell mapper 1114 collects the different audio stream and data stream classes together with the Fast Access Channel (FAC) and the Service Description Channel (SDC) of cells and places them on the time-frequency grid. The OFDM signal generator may transform each ensemble of cells with same time index to a time domain representation of the signal. Consecutively, the OFDM symbol may be obtained from this time domain representation by inserting a guard interval as a cyclic repetition of a portion of the signal.

0121A modulator converts the digital representation of the OFDM signal into the analogue signal in the air. This operation involves digital-to-analogue conversion and filtering that have to comply with spectrum requirements.

0122The data streams may consist of a packet delivery system called Packet Mode. The packet delivery system allows the delivery of asynchronous streams and files for various services in the same data stream and allows the bit rate of the (synchronous) data stream to be shared on a frame-by-frame basis between the various services.

0123Services can be carried by a series of single packets or as a series of data units. A data unit is a series of packets that are considered as one entity with regard to error handling - one received erroneous packet within a data unit causes the whole data unit to be rejected. This mechanism can be used to transfer files and also to allow simpler synchronization of asynchronous streams.

0124As shown in Fig. 10 the DRM data packet structure according to a further embodiment of the present invention comprises a packet header 1001, a packet data field 1002 and a packet CRC 1003. Again, the data packet length may be predetermined. In contrast to DAB (see Fig. 3), the packet length is not signaled in a separate header field (see packet length field 304) but may be signaled to the receiver in the Service Description Channel (SDC), for example in the format defined as application information data - type 5 in the DRM specification "Digital Radio Mondiale; System Specification" (ETSI TS 101 980, available at http://www.etsi.org).

0125It should be noted that in contrast to the definitions of the packet header and the packet data field in the DRM standard, according to the present invention, their definition is slightly different. According to an embodiment of the invention, the useful data length field 1009 indicating the length of the useful data field 1010 is considered to be part of the packet header 1001 as it may be present in all data packets due to the introduction of the error control code field 1011 to the packet data field 1002 (see paragraphs below for more details).

0126The first/last flags 1006 and the continuity index 1005 correspond to the respective first/last flags 306 and the continuity index 305 of the DAB data packet structure shown in Fig. 3 in their functionality. The packet ID 1007 corresponds to the address field 307 in the DAB packet structure of Fig. 3.

0127In a conventional DRM data packet, the PPI (Padded Packet Indicator) indicates whether the data packet comprises a useful data length field in its packet data field. If no padding is present no useful data length field is present in the packet data field and the packet data field only comprises a payload section.

0128According to this embodiment, the new DRM packet structure of Fig. 10 comprises a useful data field 1010 and an error control code field 1011 in its packet data field 1002. Hence, the PPI flag 1004 may indicate that "padding" is present for all data packets using the proposed packet structure.

0129In a further embodiment of the present invention, all data packets using this structure may omit the PPI flag 1004 in the packet header 1001, as all data packets may comprise a useful data field 1010 and an error control code field 1011 such that the useful data length field 1009 will be present in all data packets.

0130Independent of the two embodiments above, the packet data field 1002 may also include a padding field 1012 in case the desired total length of the fixed sized data packet is not reached when considering the packet header length, the useful data field length, the error control code field length and the packet CRC length. Hence, by adding a padding field in this case, the total data packet length may be matched to the desired length.

0131As described in the embodiments related to the DAB implementation issues, the error control code word may introduce error correcting capabilities to the DRM system improving the reliability of data delivery (in terms of the achieved BER) when employing the proposed packet structure. Again, the introduction of the new error control code field 1011 to the data packet structure allows a backwards-compatible implementation.

0132If the error control code and its corresponding scheme as well as the error control code field length are constant no additional signaling of these parameters may be necessary. In case of a more flexible implementation providing the freedom to choose the error control code and scheme used and optionally also the error control code field length, the parameters may be signaled to the receiver, as for the DAB related embodiments described above.

0133In contrast to the exemplary DAB implementations above, the DRM provides a Fast Access Channel (FAC) for providing the multiplex structure on the MSC, and a Service Description Channel (SDC) for signaling data related to the services provided in the MSC. Hence, the two channels together are comparable to the FIC in DAB.

0134As a consequence, the error control code field data related information, such as the error control code and scheme used and optionally also the error control code field length, may be signaled to the receiver through the SDC using for example the above mentioned application information data entity - type 5. Alternatively another data type may be defined for signaling of this information as well.