GB2399726A

GB2399726A - Transmission of multimedia objects using the Multimedia Object Transfer (MOT) protocol wherein changes are transmitted as a change index in the data stream

Info

Publication number: GB2399726A
Application number: GB0406149A
Authority: GB
Inventors: A Hartwig Koch
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2003-03-18
Filing date: 2004-03-18
Publication date: 2004-09-22
Anticipated expiration: 2024-03-18
Also published as: GB2399726B; DE10312030A1; GB0406149D0

Abstract

A process for transmission of multimedia objects (MOT objects) digitally coded in the Multimedia Object Transfer (MOT) protocol, wherein MOT objects each have a header part with information on the allocated MOT object and a body part, wherein in the data stream for transmission of a group of MOT objects, a MOT directory is transmitted with information on the MOT objects of the group, wherein changes in the MOT directory or MOT objects registered in the directory are transmitted as a change index in the data stream. The process may further involve: allocating version numbers to the MOT directory; allocating slot numbers to the header information for the MOT objects in the MOT directory wherein the slot numbers establish a sorting sequence of the MOT objects; changing the version number of the current MOT directory if a change in the MOT directory and/or a MOT object is detected; and inclusion of a change index when a change has been noted in relation to the slot number of the modified MOT object in the change index.

Description

Process for the transfer of multimedia objects and digital receiver for

multimedia objects The invention concerns a process for the transmission of multimedia objects digitally coded in the multimedia object transfer (MOT) protocol, wherein MOT objects each have a header part with information on the allocated MOT object and a body part, and wherein for a group of MOT objects a MOT directory is provided with information on all MOT objects of the group.

The invention further concerns a digital receiver for multimedia objects (MOT objects) with a reconstruction unit for decoding multimedia object data (MOD) transferred in the MOT protocol, wherein MOT objects each have a header part with information on the allocated MOT object and a body part, and wherein for a group of MOT objects a MOT directory is provided with information on all MOT objects of the group.

European ETSI standard EN 300 401 "Radio Broadcasting Systems: Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers" defines a method for broadband transmission of digital audio data. Together with the audio data, multimedia data can also be transmitted in the transport data stream. For this, European ETSI standard EN 301 234 "Digital Audio Broadcasting (DAB), multimedia object transfer (MOT) protocol" is defined. The multimedia object data, referred to below as MOD objects, can have any formats and forms such as text, images, videos, etc. The MOT protocol is also used in Digital Radio Mondial (DRM).

The multimedia object data are here transmitted in the Program Associated Data (PAD) or in the so-called packet mode of a DAB data stream. Consequently in a DAB receiver is provided a reconstruction unit known as a MOT decoder optionally at the output of the PAD decoder and/or packet mode decoder.

The multimedia object transfer (MOT) protocol provides that MOT objects comprise a header part with header core of 7 bytes and header extension, and a body part. The header part contains information on the size and content of the MOT object so that the receiver can determine whether sufficient resources are present for decoding and presentation of the MOT object. The header extension contains information to support the handling of the MOT object such as for example storage instructions. The body part contains the actual data of the multimedia object to be transferred.

For transmission a MOT object is divided into at least one separate header segment and one separate body segment. Each segment is in turn segmented into at least one data group.

The data groups are integrated into the transport data stream independently of each other and broadcast once or repeatedly. The data groups can for example be broadcast cyclically, wherein for example the data groups of a MOT object are first broadcast in succession. This procedure, called 'header mode', is then repeated several times. It is also conceivable that first a data group is broadcast repeatedly and then the next data group of the MOT object is broadcast again repeatedly, until all data groups of the MOT object have been transmitted. In cyclic transmission of the MOT object, a complete overview of all MOT objects in the receiver is not possible as the information is transferred independently and over an extended time.

For group transmission of MOT objects, the header part of all MOT objects can also be described in a MOT directory.

The header parts of the MOT objects are then normally no longer sent individually. This is called a data carousel or directory mode. This MOT directory contains not only information on the entire MOT directory such as for example the directory size, the number of objects contained in the data carousel, the repeat period of the data carousel, but also all header information of the MOT objects combined as a group in the data carousel and their transport identification numbers (transport ID).

The MOT directory, like an object, is segmented and transmitted in data groups. In addition the MOT directory is identified accordingly to distinguish it from the MOT body data. The problem here is the relatively large size required for the MOT directory due to the combined header data of all MOT objects. If the MOT directory is transmitted relatively rarely in order to reduce the bandwidth required, this however leads to a relatively long delay in identifying changes to MOT objects.

The object of the invention is therefore to create an improved method for the transfer of multimedia objects.

This object is achieved with the generic process according to the invention by the transmission of changes to the MOT directory or MOT objects registered in the MOT directory as a change index in the data stream.

It is thus proposed to provide an additional change index which indicates changes in the MOT directory or changes in MOT objects registered in the MOT directory.

This change index, to update the header part of the MOT object or the current MOT directory, can be transmitted independently of the modified MOT directory, together with a MOT directory, with header information or body information of MOT objects or independently thereof.

Preferably the change index is transmitted independently of the MOT directory so that changes can be passed on to the receiver as quickly as possible.

This is particularly advantageous if the group of MOT objects is transmitted repeatedly for example in a data carousel.

Preferably a change index is formed and transmitted when at least the header part and/or body part of a MOT object is modified in relation to a corresponding earlier MOT object.

The process preferably has the steps: Allocation of version numbers to the MOT directory, Allocation of slot numbers to the header information for the MOT objects in the MOT directory, wherein the slot numbers establish a sorting sequence of the MOT objects, - Changing the version number of the current MOT directory if a change in the MOT directory and/or a MOT object is established, and Inclusion of a change index, wherein a change has been noted in relation to the slot number of the modified MOT object in the change index.

Ordering the MOT objects marked in the MOT directory using slot numbers has the advantage that changes relating to the slot numbers can be made in the change index so that by analysis of the change index, conclusions can be drawn concerning the slot numbers of the modified MOT objects.

Using the version numbers, also modified versions of MOT directories, in particular modified change indices, can be identified in the receiver.

The change index is preferably a bit sequence with one bit per MOT object to identify a change. The bits of the MOT object in the bit sequence are particularly advantageously ordered by the slot numbers so that the allocated MOT object can be concluded directly from the individual bits.

For example bit "1" is set for unmodified MOT objects and bit "0" for modified MOT objects and these bits are arranged in succession in the order of the slot numbers.

The change index thus gives a simple binary value which can be transmitted with very little data complexity.

Unset bits in the bit sequence can be filled with defined values in the receiver, in particular with the value for unmodified MOT objects.

Furthermore it is advantageous to transmit additional information on the modified MOT objects together with the change index. This can for example be the MOT parameter transport identification (transport ID), content name, etc. It is particularly advantageous if the difference between the current MOT directory and the modified MOT directory is formed and the corresponding difference value transmitted as the change index. In a receiver then the modified MOT directory can be calculated from the stored current MOT directory and the difference value.

The object is further achieved with a digital receiver for multimedia objects (MOT objects) with a reconstruction unit for decoding multimedia object data (MOD) transmitted in the MOT protocol using the method described above, as according to the invention the reconstruction unit is designed to receive change indices and detect and update MOT directories using the change indices.

The invention is described in more detail below with reference to the enclosed drawings. These show: Figure 1 - Block diagram of a DAB receiver with MOT decoder; Figure 2 - Diagrammatic view of the division of multimedia object data into a MOT object, data segments and data groups; Figure 3 - Bit structure of the MOT directory according to standard; Figure 4 - Diagrammatic view of a data carousel with MOT directory, MOT objects, version number and change index.

Figure 1 shows a block diagram of a digital audio broadcasting receiver according to the definition of DAB standard EN 300 401. The DAB receiver has a high frequency part 1 with a subsequent signal processing unit 2 for signal decoding of a Fast Fourier Transformation OFT, with a demultiplex process and with channel decoding. The audio data stream is decoded in an audio decoder 3 and reproduced with speakers 4.

Furthermore a PAD decoder 5 is provided to decode the program associated data PAD and a packet decoder 6 for packet decoding. At the output of the PAD decoder 5 and packet mode decoder, data segments are available according to the definition of the DAB standard which are passed to a multimedia object transfer decoder 7. At least this so- called MOT decoder 7 is coupled to a data memory 8 in order to store the data of the multimedia objects transferred.

The multimedia object data MOD and possibly additional information are prepared for reproduction via a further data processing unit 9 or suitable software.

The multimedia object data MOD are transmitted segmented according to the multimedia transfer protocol. This is shown diagrammatically in figure 2. The multimedia object data MOD are divided into body segments in the body part of a MOT object. A MOT object furthermore has a header core and where applicable a header extension according to the definition of the DAB MOT standard EN 301 234. The header part is again divided into data segments K-SEG which each have a segment head SK and a segment data part SD. The segment size amongst other data is stored in the segment header.

The body segments are R-SEG are also transmitted in corresponding data segments with segment header SK and segment data part SD.

The data segments SEG are transmitted in data segments with a data group header DGH, a session header SH, a data group data field DO and optionally a MSC data group CRC. The data group header DGH contains the type of data segment SEG.

Numeral 3 indicates a header part and numerals 4 and 5 a body part.

Furthermore in the session header SH is a transport ID which identifies the associated MOT object. The data segments SEG are thus identifiable in relation to the MOT object.

The individual data segments or data groups are integrated in the transport stream temporally independently of each other and where applicable transmitted cyclically several times in succession.

For such a repeated transmission of a group of MOT objects, optionally a MOT directory is transmitted and updated at longer time intervals in succession in a so-called MOT data carousel. The headers are then transmitted in the MOT directory and normally no longer in the actual data groups.

An object can be searched for in the directory and identified via the content name of the desired object.

According to the conventional definition of MOT standard EN 301 234, version control of the objects takes place within the MOT data carousel by comparison of the transport ID and version number. On a change in MOT directory transport ID ] it is usually found that the content of the data carousel and hence a MOT object have been modified.

Figure 3 shows the currently defined structure of the MOT directory. The future structure version can be given in a 2-bit field RFU. The next 30-bit field gives the total size of the MOT directory (directory size). Then in 16 bits comes the number of MOT objects contained in the MOT directory. Then in 24 bits is the data carousel period as the maximum time which the data carousel requires to complete a cycle. Two further fields RFU and RFA are reserved for future purposes. The segment size is then given in a 13-bit field. The segment size indicates the number of bits used for segmenting the MOT objects within the MOT data carousel. A further 16-bit field is provided for the directory extension length in order to indicate the total number of successive directory extension bits. The directory extension follows with a list of parameters required to describe the entire data carousel. The structure of these parameters corresponds to the definition of the MOT header extension parameters and provides a parameter length indicator PLI, a parameter ID, an extension flag EXT, a data field length indicator and a

data field.

A number of directory entries then follow, with one directory entry n for each MOT object. Each directory entry contains a transport ID to identify the MOT object to which the next MOT header belongs. The next MOT header contains the header part and where applicable the header extension part of the object. The code structure of the MOT header corresponds precisely to the MOT headers in the data groups.

The header part contains the body size, the header size, content type, i. e. the category of the body content, and a content sub-type.

In header mode there is also a directory which however is constructed locally as a list in the receiver and transmitter from the individual header parts. This list is also referred to below as a MOT directory.

In addition it is now proposed to generate a change index for such a MOT directory and transmit this in the data stream. This change index is preferably transmitted with its own header part as a very small header, which can hence be received very rapidly, so that changes in the MOT directory can be indicated more quickly by this change index.

In order to be able to allocate changes to a specific MOT object, the individual header parts of the MOT object are sorted into virtual slots in the MOT directory. These slots are defined by an additional parameter in the header part (MOT slot number). All MOT objects have their own slot number, and duplicate slot numbers are not permitted. The slot number may only be changed when a MOT object is changed.

On each change of MOT object the version number provided in the MOT directory is incremented. A difference value is then calculated for each old version number of the MOT directory. This value can be a bit value, where a "1" is allocated to each unmodified object and a "0" to each modified object. A change occurs when the MOT object has a

IC

different content or so-called body part. It is also possible to indicate a change on new object parameters in the header part of a MOT object while the body part retains the same content.

The transmission of MOT objects in a MOT data carousel 10 with MOT directory 11 is described in an example shown in figure 4 from the viewpoint of the service provider.

The MOT objects are indicated by "A, "B", "C", "D", "E", "F" and "G". The version numbers of the MOT directory 11 are defined as serial numbers 1 to N and transmitted as entries in the MOT directory 11. A date and time are also possible as version numbers.

In version number 1 of the MOT directory 11 are first provided MOT objects A, B. C and D which are transmitted repeatedly, temporally in succession, in the MOT data carousel 10. It is also possible first to transmit MOT object "A" several times in succession, then MOT object "B" several times in succession, then MOT object "C" several times in succession and finally MOT object "D" several times in succession, wherein this sequence can also be repeated several times.

The MOT directory 11 is updated with MOT parameters 12 as so-called MOT directory updates which are transmitted as MOT parameters in the data stream to a receiver 13.

10:00 hours Start Service MOT directory Content at the time | Change index for version number (slot number is the current version of sequence) MOT directory No. 1 A, B. C, D 1111 At the start of service at 10:00, MOT directory 10 has version number 1. As a change index to the current version of the MOT directory 10, a binary "1" is entered for each MOT object in the series of slot numbers of MOT objects.

This means that the MOT objects are unchanged.

11:00 hours MOT directory Content at the time Change index for version number (slot number is the current version of sequence) MOT directory No. 2 A, E, C, D 1111 No. 1 A, B. C, D 1011 At 11:00 a MOT directory 11 with version number 2 is transmitted, wherein now MOT objects A, E, C and D are transmitted. MOT object "B" has been replaced by the MOT object "E". The change index in the current version number 2 of the MOT directory 11 provides the entry "1" for the MOT object i.e. in comparison with the current version there is no change.

For the previous MOT directory 11 with version number 1, the change index provides an entry "0" at the second position for MOT object "B" in slot number/slot position 2.

From the bit sequence of the change index it is thus evident that the second MOT object "B" has been changed.

At 12:00 a new MOT directory 11 is transmitted with version number 3 in which MOT objects A, E, F. D are provided. The 1' change index for this current version number 3 of the MOT directory 11 again has the entry "1" for all MOT objects as these are unchanged in relation to the current version number 3 of the MOT directory 11.

12:00 hours MOT directory Content at the time Change index for version number (slot number is the current version of sequence) MOT directory No. 3 A, E, F. D 1111 No. 2 1 A, E, C, D 1101 No. 1 A, B. C, D 1001 The previous MOT directory 11 with version number 2 now contains a change index in relation to the current version number 3 in which a binary "0" is entered for the third slot number. The third MOT object "C" has namely been changed into MOT object "F" in the new MOT directory 11 with version number 3. All other MOT objects remain the same so the entry for these in the change index is a "1".

For the MOT directory 11 with version number 1, the change index relating to the current version number 3 of the MOT directory 11 is consequently modified in that a change is indicated by the binary entry "0" for the second slot number and third slot number. The first and fourth slot numbers of the change index, however, remain unchanged.

At 13:00 hours a further MOT directory 11 is transmitted with version number 4. Here the third MOT object "F" is replaced by MOT object "G", so that in the change index at the third position a change is indicated in the previous versions of the MOT directory 11. 1;

13:00 hours MOT directory Content at the time Change index for version number (slot number is the current version of sequence) MOT directory No. 4 A, E, G. D 1111 No. 3 A, E, F. D 1101 No. 2 A, E, C, D 1101 No. 1 A, B. C, D 1001 Together with the relevant version number, the change index in the corresponding header is now preferably transmitted with the content "Content type: MOT-Transport, Content Sub-Type: Directory Update".

The MOT parameters in the header part are as follows: MOT parameters MOT directory Change index as version number Bit pattern MOT directory update l l OT directory update... ...

MOT directory update In the header only the previous versions of the MOT directory 11 are transmitted. As an option, version numbers can be omitted if there is no difference from the previous change index, for example between 12:00 or 11:00 and 13:00.

In this case the older version number is sent and the receiver automatically takes the nearest available previous version of the MOT directory 11.

Furthermore the change index of the current version is always "1", i.e. redundant. This index need not therefore be sent. 1(

The transmitted optimised MOT parameter 12 for the MOT directory changes at 13:00 are for example as follows: MOT parameter Version number Change index MOT directory update 2 1101 MOT directory update 1001 If the required local version of the MOT directory 11 is not available on the receiver side, and no older version is available, then either a complete change of MOT directory 11 can be assumed or it can be concluded that the complete MOT directory 11 must be awaited.

It is now possible to compress the data transmission if a standard value is assumed for untransmitted slot numbers of the version concerned. For example all missing numbers can be established as unchanged. This however only applies for the slot numbers at the end of the MOT directory 11. As the actual length of the MOT directory 11 is unknown, the missing values of the change index can easily be completed in the receiver.

Example with compression at 13:00 (Figure 4d): MOT parameter Version number Change index I MOT directory update 110 MOT directory update 100 Furthermore a change index can be compiled from identical parts or pieces of newer indices.

A receiver 13 will be able to receive this header 12 very much faster than the entire current MOT directory 11. Thus in receiver 13 from the information in header 12 the Is version of the local MOT directory 11 can be found and all MOT objects immediately deleted from the now obsolete MOT directory list 11 available only in the receiver. Old MOT objects thus need not be offered to the user.

It is furthermore possible to send more detailed information on the modified MOT objects together with the difference values. Thus for example the MOT parameters transport ID, content name, etc. can be sent in the MOT directory update.

A complete difference value of the current MOT directory 11 can also be generated, where the binary value of the current MOT directory 11 is subtracted from the binary value of the previous MOT directory 11. This difference value is now transmitted as a change index. In the receiver, from the difference value and the old MOT directory 11 present in the receiver, the current MOT directory 11 can be calculated with all entries by summing the difference values.

The update to the MOT directory 11 can be sent separately from the MOT directory 11 or together with it. It can be sent either with the MOT directory 11 and the MOT objects, with the MOT headers and MOT objects, or with the MOT directory 11, MOT headers and MOT objects.

In any case, however, new MOT objects can only be presented after reception of the new MOT directory 11 as only then are all parameters known. It is however to be assumed that the decoding of these new objects takes somewhat longer than the reception of the new MOT directory 11. 1w

In addition the modified header parts of the modified MOT objects can also be sent before a MOT object and hence the header mode used, so that it is not necessary to wait for complete reception of the MOT directory 11.

As an extension the transmission of the MOT directory 11 can also be omitted completely. The MOT object headers are transmitted individually in header mode. The change index here serves as a connecting bracket over all objects.

With the proposed MOT directory update, the MOT directory 11 can be sent much more rarely than before so the required overhead is substantially reduced. In addition changes in the data carousel 10 are available to the receiver more quickly.

Claims

Claims 1. Process for the transmission of multimedia objects (MOT objects)

digitally coded in the multimedia object transfer (MOT) protocol, wherein MOT objects each have a header part with information on the allocated MOT object and a body part, and wherein for a group of MOT objects a MOT directory (11) is provided with information on all MOT objects of the group, characterized by the transmission of changes to the MOT directory (11) or MOT objects registered in the MOT directory as a change index in the data stream.
2. Process according to any one of the previous claims, characterized by the formation and transmission of a change index when at least the header part and/or the body part of a MOT object is modified in relation to a corresponding earlier MOT object.
3. Process according to any one of the previous claims, characterized by allocation of version numbers to the directory, in particular the MOT directory (11), - allocation of slot numbers to the header information for the MOT objects in the MOT directory (11), wherein the slot numbers establish a sorting sequence of the MOT objects, - changing the version number of the current MOT directory (11) if a change in the MOT directory (11) and/or a MOT object is established, and - inclusion of a change index, wherein a change has been noted in relation to the slot number of the modified MOT object in the change index. Li
4. Process according to any one of the previous claims, characterized in that the change index is a bit sequence with one bit per MOT object to identify a change.
5. Process according to claim 4, characterized in that the entries in the change index for the MOT objects are ordered in the sequence of the slot numbers.
6. Process according to any one of the previous claims, characterized by the filling of unset bits in the bit sequence of the change index with established values and/or filling of unset bits from constituents of newer change indices.
7. Process according to any one of the previous claims, characterized by comparison of the change index of a subsequent version of a MOT directory (11) with the previous version and omission of the subsequent version on transmission of MOT directories (11) if the change index is the same.
8. Process according to any one of the previous claims, characterized by transmission of additional information on the modified MOT objects together with the change index.
9. Process according to any one of the previous claims, characterized by formation of the difference between the current MOT directory (11) and the modified MOT directory (11) and transmission of the difference value as a change index, wherein in a receiver the 1'i modified MOT directory (11) can be calculated from the stored current MOT directory (11) and the difference value.
10. Digital receiver for multimedia objects (MOT objects) with a reconstruction unit for decoding multimedia object data (MOD) transmitted in the MOT protocol using the process according to any one of the previous claims, wherein MOT objects each have a header part with information on the allocated MOT object and a body part, and wherein for a group of MOT objects a MOT directory (11) is provided with information on all MOT objects of the group, characterized in that the reconstruction unit is designed to receive change indices and detect and update MOT directories (11) using the change indices.
11. Process substantially as hereinbefore described with reference to the accompanying drawings.
12. Digital receiver substantially as hereinbefore described with reference to the accompanying drawings. it