Method and device for the transmission of data in a television system

METHOD AND DEVICE FOR THE TRANSMISSION OF DATA IN A TELEVISION SYSTEM

This application claims the benefit under 35 U.S.C. §365 of International Application PCT/EP01/12333 filed Oct. 18, 2001, which claims the benefit of European patent application No. 00402921.1 filed Oct. 23, 2000.

FIELD OF THE INVENTION

The invention concems a method for transmitting data in a television system, as well as an emitter and a receiver in such a system. The invention applies in particular, but is not limited to, systems implementing the ATVEF specification.

BACKGROUND INFORMATION

Television receivers are being developed to host resident interactive services, transmitted for example through a bidirectional retum channel or simply broadcast over the same channel as the video signal. In this context, ATVEF (Advanced TeleVision Enhancement Forum) specifies the use of a number of protocols such as IP multicast (Internet Protocol multicast) for transporting data for interactive television program enhancement services over a number of transmission media.

According to the ATVEF specification, when a service provider wishes to transmit an interactive service, he first has to transmit a message called an announcement, containing information describing the interactive service. This announcement is transmitted to a specific IP multicast address and to a specific port, known to all receivers (IP address 224.0.1.113 and UDP Port 2670).

Receivers compatible with the ATVEF specification continuously monitor this address/port couple. Their resident software modules retrieve the announcement, which contains a pair of IP addresses, one for the transmission of the interactive service (called the ‘content’), another one of the transmission of triggers. Triggers are messages for triggering a certain behavior of interactive services at predetermined moments.

Software modules resident in the receivers may require updates. For flexibility reasons, it should be possible to make such an update in remote fashion, i.e. to transmit the updated software modules to the receivers in situ. Such a transmission should obviously use some of the already available transmission media, such as the return channel (be it through the PSTN or the cable network, or another type of bi-directional communication means) or the television broadcast medium.

The ATVEF protocol stack (see FIG. la) carmot be used directly to transmit the update—or other types of binary data—, because the software in charge of retrieving the interactive service (e.g. a browser) is not able to interpret the content data which represents the resident software module update. This update is typically binary data, instead of the UHTTP data expected by the browser. This could result in unpredictable behavior at the receiver level. Modifying the browser to detect and process binary data would be impractical. In addition, transporting binary data using UHTTP is cumbersome, since this protocol has not been developed for such a purpose.

Nevertheless, it is desired to respect as much a possible the ATVEF protocol, to remain within the constraints defined by the broadcast tools.

SUMMARY OF THE INVENTION

The object of the invention is a method for transmitting binary data in a video transmission system comprising the steps of:

providing ATVEF announcements on a first predefined IP

multicast address;

providing ATVEF trigger and/or content transmission on a

first range of IP multicast addresses;

providing non-ATVEF announcements on a second pre

defined multicast address different from said first address;

providing non-ATVEF data transmission on a second

range of IP multicast addresses, exclusive of the first range.

According to an embodiment of the invention, said system comprises an emitter comprising a data inserter for inserting ATVEF and non-ATVEF information into a transmission signal, said method further comprising the steps of:

providing ATVEF announcements and non-ATVEF

announcements to the data inserter,

dynamic insertion of IP multicast addresses by the data

inserter into the amrouncements, in accordance with the first and second ranges.

According to an embodiment of the invention, the method further comprises the step of splitting each of the first and/or the second range of IP multicast addresses into a third and a fourth range, where the third range is reserved for automatic address detennination by the data inserter, and the fourth range is reserved for addresses which are predefined in the announcements provided to the data inserter.

According to an embodiment of the invention, ranges are distinguished by different IP address ranges, different port ranges or both.

According to an embodiment of the invention, at the level of a receiver, the method further comprises the steps of:

receiving a non-ATVEF announcement amrouncing trans

mission of receiver software update data, said announcement containing an IP multicast address on which signaling data describing the update data transmission is to be sent;

lister1ing to the address specified in the announcement;

retrieving the signaling data and storing it in a memory

which is not erased during download of the update data; launching of a loader program;

having the loader program retrieve the stored signaling

data; and

proceeding with the download of the update data based on

the stored signaling data.

Another object of the invention is an emitter device for broadcasting announcements in a transmission system compatible with ATVEF transmissions, characterized in that it comprises means for transmitting ATVEF announcements on a first predefined IP multicast address, ATVEF trigger and/or content data on a first range of IP multicast addresses, binary data announcements on a second predefined IP multicast address different from the first predefined address and binary data on a second range of IP multicast addresses, wherein the first and second address ranges are exclusive of each other.

According to an embodiment of the invention, the emitter comprises means for receiving an amrouncement, for determining whether the announcement comprises a predetermined IP multicast address in a first range, and in the negative, for selecting an IP multicast address in a second range, distinct from the first range, and for inserting the selected IP multicast address into the amrouncement.

3

Another object of the invention is a receiver in an ATVEF compatible transmission system, characterized in that it comprises a memory for storing a first predefined IP multicast address for receiving ATVEF announcements, and a second predefined IP multicast address for receiving announcements relating to the transmission of binary data, where the first and second addresses are distinct.

According to a variant embodiment, the receiver further comprises a memory for receiving a third multicast address on which binary data transmission is announced, said memory being such as to maintain the multicast address during a receiver reboot process, said receiver further comprising means for listening to the third multicast address in the memory after reboot for downloading the binary data from said third multicast address.

According to an embodiment, the third multicast address on which binary data transmission is announced is provided in signaling data announced on said second multicast address.

According to an embodiment, the downloadedbinary file is a complete system update.

Other characteristics and advantages of the invention will appear through the description of a detailed, non-limiting embodiment, explained with the help of the attached drawings, among which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1a (prior art) represents an ATVEF protocol stack;

FIG. 1b represents a protocol stack of a device according to the embodiment;

FIG. 2 represents the software structure of a receiver, as well as different applications and tasks and their evolution upon reception of an announcement;

FIG. 3 is a flowchart of the processing of announcements and data by a receiver according to the invention;

FIG. 4 is a flowchart of the processing of announcements in a broadcast server;

FIG. 5 is a schematic diagram illustrating the principle of acquiring an IP multicast address in a first step when the receiver is in nominal mode and using the stored IP multicast address in a second step during which the receiver is in a loader mode;

4

Session Description

vrprotocol version, equal to 0

O:l.1S€I'I12lII1€, session identifier, version, network type

(equal to IN in the present case), address type (equal to IP4 in the present case), ipaddress

s:session name

i:session infonnation (optional)

u:Universal Resource Identifier (U RI) of a description of

the enhancement (optional)

e:email address

prphone number (at least one of the e and p parameters is

required)

b:CT:number (bandwidth information)

c:connection inforlnation

The following session attributes can or must be used:

a:UUID:UUID (Universally Unique Identifier: unique

enhancement identifier-optional)

aitype:tve

a:lang, a:sdplang (optional language attributes)

aitve-type:<types> (optional)

2l:IV€-S1Z€Z Kbytes

2l:IV€-l€V€lZX (optional)

2l:tV€-€I1dSZ seconds (optional)

Media Description

m:(media name and transport address)

Time Description

t:(time during which the session is active)

As has already been mentioned in the introduction, ATVEF announcements are sent to a predefined IP address (224.0.1.113) and a predefined UDP port number (2670).

The parameter ‘c’ of an announcement indicates to which address content and triggers will be sent, while the parameter ‘m’ indicates on which port they will be sent. Triggers and content may be sent on different ports at the same address, as well as on different addresses.

The present embodiment concerns an analog television system in which the vertical blanking interval lines of the analog video signal are used to transmit digital data. Modulation of this kind of data on an analog television signal is well known per se.

FIG. 1b is a diagram of the protocol stack used by a receiver in conformance with the present embodiment. Compared to the ATVEF stack of FIG. 1a, the UHTTP layer has been replaced by a proprietary layer. The stack includes UDP (User Datagram Protocol) over IP (Internet Protocol), SLIP (Serial Line Internet Protocol) and IDL-B, as defined in ETS 300 708.

The role of the proprietary layer is to manage binary data downloading. The binary data to be downloaded is split into sections having the size of IP packet payloads, i.e. 1472 octets. The layer assembles the different sections it receives in the right order. If a section contains uncorrectable errors, then the proprietary layer waits for a next transmission (see below) and inserts it at its proper place.

The proprietary layer also retrieves date/time inforlnation and announcements relating to binary data downloads and date/time infonnation.

Enhancements and binary data are usually sent repeatedly, in order to enable receivers to access the corresponding data even when they do not listen from the beginning of the transmission, and in order to retrieve packets which were previously received with uncorrectable errors.

According to the present embodiment, in order to announce the transmission of binary data, an announcement of the SDP format is made at another address and port than the address and port used by the ATVEF announcements. Accordingly, as an example, the receiver listens to the address