Field of the Invention
[0001] 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, 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
[0002] The 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).
[0003] DAB 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.
[0004] The 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
[0005] The 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
[0006] The 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.
[0007] The 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.
[0008] It 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
[0009] The main service channel (MSC) 104 is the largest portion of the DAB ensemble carrying
the major portion of the transmission data.
[0010] An 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.
[0011] The 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.
[0012] Each 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.
[0013] The 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
[0014] DAB 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).
[0015] Depending 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.
[0016] In 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.
[0017] The 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
[0018] The object of the present invention is to increase the number of data packets of
which undamaged data can be derived under identical reception condition.
[0019] The object is solved by the subject matter of the independent claims. Advantageous
embodiments of the present invention are subject matters to the dependent claims.
[0020] One 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.
[0021] An 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.
[0022] According 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.
[0023] In 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.
[0024] Another 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.
[0025] In 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.
[0026] Moreover, 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.
[0027] In 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.
[0028] As 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.
[0029] According to another embodiment of the present invention the formed data packet is
comprised within a main service channel of the transmission frame.
[0030] The 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.
[0031] According 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.
[0032] The 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.
[0033] As 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.
[0034] According 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.
[0035] The 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.
[0036] A 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.
[0037] Another 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.
[0038] Moreover, 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.
[0039] A 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.
[0040] An 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.
[0041] Further, 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
[0042] In 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.
- Fig. 1
- shows an exemplary overview of the structure of a transmission frame in DAB,
- Fig. 2
- shows an exemplary overview of the structure of a fast information group (FIG) in
DAB,
- Fig. 3
- shows a DAB data packet structure according to an embodiment of the present invention,
- Fig. 4 & 5
- 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,
- Fig. 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,
- Fig. 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,
- Fig. 8
- shows a conceptual DAB emission block diagram according to an embodiment of the present
invention,
- Fig. 9
- 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,
- Fig. 10
- shows a DRM data packet structure according to an embodiment of the present invention,
- Fig. 11
- shows a conceptual DRM emission block diagram according to an embodiment of the present
invention, and
- Fig. 12
- shows a conventional data packet structure of the DAB standard.
Detailed Description of the Invention
[0043] On 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.
[0044] The 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.
[0045] Next, 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.
[0046] The 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.
[0047] If 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.
[0048] The 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.
[0049] The 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.
[0050] The 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.
[0051] The 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.
[0052] Packet 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.
[0053] In 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.
[0054] The 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.
[0055] Finally, 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.
[0056] Each 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.
[0057] Therefore 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.
[0058] Also 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).
[0059] In 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.
[0060] However, 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.
[0061] In 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.
[0062] Next, 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 & error control coder 814.
[0063] The packet builder & 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 & error control coder 814. Further,
the packet builder & 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.
[0064] The packet builder & 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.
[0065] The 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.
[0066] Further, 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.
[0067] The 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.
[0068] Digital 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).
[0069] The 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.
[0070] Next, 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)
which are output 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.
[0071] The 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.
[0072] The 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.
[0073] The 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 & 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.
[0074] Taking 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.
[0075] The 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.
[0076] Fig. 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.
[0077] Each 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).
[0078] In 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.
[0079] The 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.
[0080] The 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.
[0081] The 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.
[0082] Each 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.
[0083] The 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.
[0084] Following 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.
[0085] In 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.
[0086] By 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.
[0087] The 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.
[0088] In 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.
[0089] In 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.
[0090] The 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.
[0091] Next, 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.
[0092] Further, 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.
[0093] Once 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.
[0094] In 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.
[0095] Further, 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.
[0096] The 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).
[0097] As 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.
[0098] It should be noted that in a further embodiment of the present invention, steps 401
to 409 may be performed in the packet builder & 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.
[0099] Next, 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.
[0100] Fig. 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.
[0101] Upon 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.
[0102] Having 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.
[0103] In 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.
[0104] Fig. 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.
[0105] After 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.
[0106] If 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.
[0107] It 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.
[0108] However, 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.
[0109] Hence, 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.
[0110] Further, 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.
[0111] For 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.
[0112] Further, 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).
[0113] The 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.
[0114] Figure 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.
[0115] The 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.
[0116] The pre-coder & 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
& 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 &
error control coder 1102 provides the information of the error control code field
and inserts same into the data packets for each data stream.
[0117] The 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.
[0118] The 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.
[0119] Cell 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.
[0120] The 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.
[0121] A 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.
[0122] The 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.
[0123] Services 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.
[0124] As 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).
[0125] It 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).
[0126] The 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.
[0127] In 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.
[0128] According 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.
[0129] In 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.
[0130] Independent 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.
[0131] As 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.
[0132] If 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.
[0133] In 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.
[0134] As 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.
1. 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
comprising:
a packet header enabling the identification (307, 1007) of the data stream and the
length (309, 1009) of application data in a packet data field,
the packet data field (302, 1002) comprising a field (310, 1010) with said application
data of the data stream, and
wherein the packet data field (302, 1002) further comprises an error control code
field (311, 1011) generated based on at least a part of the packet data field (302,
1002) and/or at least a part of the packet header (301, 1001).
2. The data packet structure according to claim 1, wherein information of said error
control code field (311, 1011) is generated using a Reed-Solomon code or a turbo code
or another forward error correction code.
3. The data packet structure according to claim 1 or 2, wherein the packet data field
further comprises a padding field (312, 1012) for providing padding bits to match
the data packet length to the predetermined packet length.
4. The data packet structure according to one of claims 1 to 3, wherein the structure
further comprises a CRC field calculated based on the packet header (301, 1001) and
the packet data field (302, 1002).
5. A method for transmitting a packet-based data stream in a digital audio broadcasting
system, the method comprising the steps of:
generating (401) a packet header (301, 1001) enabling the identification of the data
stream and the length of application data in a packet data field,
generating (403) a packet data field (302, 1002) comprising a field with said application
data of the data stream and an error control code field (311, 1011 ),
generating (402) the error control code field (311, 1011) based on at least a part
of the packet data field (302, 1002) and/or at least a part of the packet header (301,
1001),
concatenating (404) at least the packet header (301, 1001) and the packet data field
(302, 1002) to form a data packet,
generating (504) a transmission frame (101) comprising the formed data packet, and
transmitting (508) the transmission frame (101).
6. The method according to claim 5, wherein the error control code field (311, 1011)
is generated using at least one error control code of at least one corresponding error
control code scheme.
7. The method according to claim 6, further comprising the step of signaling information
(218) 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 in an information
data stream (103) being part of the transmission frame (101).
8. The method according to one of claims 5 to 7, wherein the formed data packet is comprised
within a main service channel (104) of the transmission frame (101).
9. The method according to one of claims 5 to 8, comprising the step of using application
information carried in the information data stream (103) for associating the information
on the length of the error control code field (311, 1011), the at least one used error
control code and the corresponding at least one error control code scheme with said
data stream carrying the data for a corresponding application instance.
10. A method for receiving a packet-based data stream in a digital audio broadcasting
system, the method comprising the steps of:
receiving (601) a transmission signal comprising said data stream,
extracting at least one transmission frame (101) comprising said data stream from
the transmission signal,
extracting (605) a main service channel (104) from the transmission frame (101),
extracting (606) from the main service channel (104) at least one data packet used
to transmit said data stream, wherein the at least one data packet comprises a packet
header (301, 1001) and a packet data field (302, 1002) comprising application data
of said data stream and an error control code field (311, 1011) and
verifying (608, 702) the data integrity of at least a part of the packet header (301,
1001) and/or at least a part of packet data field (302, 1002) using information in
the error control code field (311, 1011).
11. The method according to claim 10, further comprising the steps of:
extracting (602) an information data stream from the transmission frame and
extracting (603) 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.
12. The method according to claim 11, wherein information on the length of the error control
code field is extracted in the step of extracting the information.
13. The method according to one of claims 10 to 12, wherein the information in the error
control code field protects at least a part of the data packets used to transmit the
data for an application instance.
14. The method according to one of claims 10 to 13, further comprising the step of 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.
15. The method according to one of claims 10 to 14, further comprising the step of extracting
application information (206, 207, 208) from the information data stream enabling
the identification of data packets belonging to the data stream and
associating the data packets with the information on the at least one error control
code, the corresponding at least one error control code scheme and the error control
code length based on the data (217) in the application information (206, 207, 208)
.
16. A transmitter (902) for transmitting a packet-based data stream in a digital audio
broadcasting system, the transmitter comprising:
means (814, 1102) for generating (401) a packet header (301, 1001) enabling the identification
of the data stream and the length of application data in a packet data field,
wherein the means (814, 1102) is adapted to generate (403) a packet data field (302,
1002) comprising a field with said application data of the data stream and an error
control code field (311, 1011),
to generate (402) the error control code field (311, 1011) based on at least a part
of the packet data field (302, 1002) and/or at least a part of the packet header (301,
1001),
and to concatenate (404) at least the packet header (301, 1001) and the packet data
field (302, 1002) to form a data packet,
multiplexing means (813, 1114) for generating (504) a transmission frame (101) comprising
the formed data packet, and
transmission means for transmitting (508) the transmission frame (101).
17. The transmitter (902) according to claim 16, comprising means being adapted to perform
the method according to one of claims 5 to 9.
18. A receiver for receiving a packet-based data stream in a digital audio broadcasting
system, the receiver comprising:
reception means for receiving (601) a transmission signal comprising said data stream,
and
processing means for extracting at least one transmission frame (101) comprising said
data stream from the transmission signal,
wherein the processing means is adapted to extract (605) a main service channel (104)
from the transmission frame (101),
to extract (606) from the main service channel (104) at least one data packet used
to transmit said data stream, wherein the at least one data packet comprises a packet
header (301, 1001) and a packet data field (302, 1002) comprising application data
of said data stream and an error control code field (311, 1011) and
to verify (608, 702) the data integrity of at least a part of the packet header (301,
1001) and/or at least a part of packet data field (302, 1002) using information in
the error control code field (311, 1011).
19. The receiver (903) according to claim 18, the receiver (903) comprising means adapted
to perform the method according to one of claims 10 to 15.
20. A digital audio broadcasting system for transmitting data from a transmitter (902)
to a receiver (903) using the data packet structure of one of claims 1 to 4.
21. The digital audio broadcasting system according to claim 20, wherein the transmitter
(902) is a transmitter according to claim 16 or 17 and the receiver (903) is a receiver
according to claim 18 or 19.