[0001] The invention concerns 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.
[0002] Television receivers are being developed to host resident interactive services, transmitted
for example through a bi-directional return 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.
[0003] 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).
[0004] 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.
[0006] 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.
[0007] The ATVEF protocol stack (see figure 1a) cannot 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.
[0008] Nevertheless, it is desired to respect as much a possible the ATVEF protocol, to
remain within the constraints defined by the broadcast tools.
[0009] An object of the invention is a method for transmitting as claimed in claim 1.
[0010] Another object of the invention is a method for receiving as claimed in claim 5.
[0011] Another object of the invention is an emitter as claimed in claim 7.
[0012] Another object of the invention is a receiver as claimed in claim 9.
[0013] 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:
- figure 1a (prior art) represents an ATVEF protocol stack;
- figure 1b represents a protocol stack of a device according to the embodiment;
- figure 2 represents the software structure of a receiver, as well as different applications
and tasks and their evolution upon reception of an announcement;
- figure 3 is a flowchart of the processing of announcements and data by a receiver
according to the invention;
- figure 4 is a flowchart of the processing of announcements in a broadcast server;
- figure 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;
- figure 6 is a schematic diagram of a network comprising an emitter and receivers according
to the present embodiment.
[0014] In the figures, the symbol '@' is used to designate an address.
[0015] More information concerning the ATVEF specification can be found in the document
"Enhanced Content Specification" ATVEF (Advanced TeleVision Enhancement Forum) Specification
v 1.1 r26. This document is available for example on the ATVEF website (www.atvef.com).
[0016] Reference is also made to the document 'SDP: Session Description Protocol', Internet
Society, Network Working Group, RFC 2327 of April 1998, available at ftp.isi.edu/in-notes/rfc2327.txt.
[0017] Announcements according to the ATVEF specification follow the format described in
the SDP document mentioned in the previous paragraph, though ATVEF imposes some restrictions
for some parameters. Parameters used in an SDP announcement according to the ATVEF
specification are as follows:
Session description
[0018]
v= protocol version, equal to 0
o= username, 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 information (optional)
u= Universal Resource Identifier (URI) of a description of the enhancement (optional)
e= email address
p= phone number
(at least one of the e and p parameters is required)
b= CT:number (bandwidth information)
c= connection information
[0019] The following session attributes can or must be used:
a= UUID:UUID (Universally Unique Identifier: unique enhancement identifier - optional)
a= type:tve
a= lang, a= sdplang (optional language attributes)
a= tve-type:<types> (optional)
a= tve-size: Kbytes
a= tve-level:x (optional)
a= tve-ends:seconds (optional)
Media description
m= (media name and transport address)
Time description
t= (time during which the session is active)
[0020] 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).
[0021] 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.
[0022] 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.
[0023] Figure 1b is a diagram of the protocol stack used by a receiver in conformance with
the present embodiment. Compared to the ATVEF stack of figure 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.
[0024] 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.
[0025] The proprietary layer also retrieves date/time information and announcements relating
to binary data downloads and date/time information.
[0026] 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.
[0027] 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 235.0.1.113, port number 2670, to detect these novel
types of announcements. In parallel, the receiver continues to listen to the standard
ATVEF announcement address and port.
[0028] Figure 2 is a diagram of an example of the applications and tasks that a receiver
according to the present embodiment runs in parallel according to the present embodiment.
Of course, other applications and tasks may also run, but are not directly relevant
to the present embodiment. The receiver listens to six different IP multicast addresses,
numbered A1 to A6. An IP multicast address comprises an IP address and a port number.
An ATVEF announcement is sent to the well-known ATVEF address/port couple A1 as already
described above. ATVEF content and triggers ('ATVEF data') is sent to two different
address/port couples, A3 and A4, which are specified by the ATVEF announcement. Two
different non-ATVEF announcements are sent to predefined, fixed address/port A2. The
first one indicates an address/port A5 for retrieving date and time information, while
the second one indicates an address/port A6 for retrieving the binary data.
[0029] Applications of figure 2 act upon a socket layer 4 to listen to the required IP multicast
addresses. The socket layer 4 operates over an operating system 5 including a VBI
Driver (which is not illustrated). The Vertical Blanking Interval (VBI) driver retrieves
data from the VBI of the incoming analog video signal. Of course, in case another
transmission path were used (e.g. all digital television signal such as an MPEG II
Transport Stream), another driver than the VBI Driver would be used. The retrieved
data is under a packet format called IDLB. The driver extracts the payload from these
packets and applies an error correction process. The payload is a SLIP-format stream
which enables the driver to identify and separate IP packets. Once the SLIP layer
has been removed and the IP packets have been reconstructed, the driver hands these
packets over to the upper layers in charge of de-encapsulating the IP and UDP layers.
The browser 1 and the other applications are clients of the socket layer 4 which enables
them to listen to an IP address and a UDP port in order to retrieve the transmitted
content.
[0030] The upper part of figure 2 will be described first. The upper and lower parts show
the receiver's state at different moments in time.
[0031] The receiver runs a browser 1 in charge of retrieving respectively the ATVEF announcements,
content and triggers and listens respectively to addresses A1, A3, A4, which the browser
1 has programmed at the socket level). In figure 2, it is supposed that at least one
announcement has already been received. The browser may also listen to other addresses,
which are not shown on figure 2. A first task 2 ('Binary data fetching manager') is
in charge of retrieving the non-ATVEF announcements sent on address A2. A second task
3 ('Code download signaling data retriever') is used to retrieve the binary file itself
on an address A6. The address A6 has previously been specified in a binary announcement
on address A2. Two different tasks are used to retrieve the update announcement and
the update file itself: this avoids having to sort the incoming data relating to these
addresses.
[0032] The second task 3 need not be active all the time. It can be triggered by the first
task 2, upon reception of an announcement relating to the kind of data retrieved by
the second task 3.
[0033] According to the present embodiment, the 'i' field of an announcement is used to
inform the task 2 of the nature of the data to be transmitted. For example, 'i' is
equal to 'code download' for the transmission of binary data, and equal to 'date&time'
for the transmission of the date and time information.
[0034] Contrary to ATVEF announcements, the announcement according to the present embodiment
contains only one address and associated port value, to indicate to the receiver where
to listen for the transmission of the binary data (code update, time, or other).
[0035] According to the present embodiment, such an announcement contains the following
parameters relating to the address and port of the update file:
m = data 22814 tvpe-file c=IN IP4 235.37.32.27.
[0036] Other parameters are similar to those used in ATVEF announcements. This is given
as an example: other values may be used as well.
[0037] As an example, a non-ATVEF announcement contains the following fields:
"v=0" see ATVEF
"i=XXX" see below
"a=UUID:XXX" see ATVEF
"a=tve-ends:XXX" or "t-start stop" see ATVEF
"m=data XXX tve-file" see above and ATVEF
"c=IN IP4 XXX" see above and ATVEF
[0038] Figure 2 also illustrates the dynamics of announcement handling in the receiver.
The upper part of figure 2 shows the receiver's task at a time t. At this time, the
browser 1 listens to its predetermined ATVEF announcement address A1, and to two further
addresses for content (A3) and triggers (A4). The binary data fetching module 2 listens
to the address corresponding to binary data announcements.
[0039] At a given time, a binary announcement concerning the transmission of date and time
is received by the binary data fetching module 2. This announcement contains an IP
multicast address A5 on which data and time information is due to be transmitted.
As illustrated by the lower part of figure 2, a third task 6, named 'Date and time
data retriever' is launched, in order to listen to the address A5 specified in the
announcement.
[0040] Figure 3 is a flowchart which further illustrates the processing of ATVEF and non-ATVEF
announcements and data in the receiver.
[0041] It must be noted that from the point of view of the implementation, the test of whether
an announcement is an ATVEF announcement or not corresponds in fact to the filtering
carried out using the different IP multicast addresses.
[0042] The field "a=UUID" serves to identify the announcement. If the proprietary layer,
in its role of binary data fetching module, already received an announcement with
the same UUID value although the expiration date of this announcement has not yet
been reached, the new announcement is ignored. It is up to the operator to modify
the UUID value in order to inform receivers of an announcement content change. This
mechanism avoids having to further process announcements if their UUIDs correspond
to those of already existing announcements.
[0043] When preparing an announcement, the service provider or the broadcaster's emitter
selects the address values for data transmission in a certain range. According to
the present embodiment, one such range is reserved for ATVEF transmissions, while
another such range is reserved for non-ATVEF transmissions (e.g. software module updates
according to the present example). This avoids having ATVEF data sent to non-ATVEF
addresses and vice-versa.
[0044] Through this mechanism, different kinds of services may easily be multiplexed.
[0045] Figure 4 is a flowchart of the announcement creation process in a server, showing
how IP multicast addresses are automatically selected and inserted into announcements
by the emitter in the absence of preset addresses.
[0046] In a preferred embodiment, the broadcaster receives the ATVEF or non-ATVEF announcements
and dynamically adds through its emitter the content, trigger or binary data transmission
addresses according to the predefined ranges.
[0047] As an example, the following address range is used for sending ATVEF enhancements
on manually attributed addresses:
224.0.0.0 to 224.0.1.112 port numbers 0 to 2669.
[0048] The following address range is used for sending ATVEF enhancements on automatically
attributed addresses:
224.0.1.114 to 234.255.255.255, port numbers 2671 to 65535.
[0049] The following address range is used for sending binary files on manually attributed
addresses:
235.0.0.0 to 235.0.1.112, port numbers 0 to 2669.
[0050] The following address range is used for sending binary files on automatically attributed
addresses:
235.0.1.114 to 239.255.255.255, port numbers 2671 to 65535.
[0051] Manually attributed addresses are addresses which are predetermined in announcements
received by the emitter from e.g. the service provider, i.e. the emitter does not
itself select such addresses, as opposed to announcements were such a choice is made
automatically by the emitter, when at least one address is missing in an announcement.
Different address ranges are used to avoid having the emitter pick an address which
has already been defined manually in another announcement.
[0052] According to a variant embodiment, the address ranges used for ATVEF and non-ATVEF
data transmissions are the same or at least overlap to a certain extent, but the port
number ranges attributed to each kind of data transmission do not overlap. In other
words, there will still be different IP multicast address ranges.
[0053] The two address ranges may be modified. In this case, an update mechanism is put
in place at the receiver.
[0054] A variant embodiment, illustrated by figure 5, will now be described. This embodiment
concerns the case in which the binary data to be downloaded may influence - and in
particular interrupt - certain processes of the receiver.
[0055] One can consider a receiver in which downloading of executable code, for example
all updatable code stored in a flash memory of the receiver, is to be performed. The
receiver comprises a loader program 7 in order to perform the download. This program
is stored in ROM, since all code stored in the flash memory is to be replaced.
[0056] The process in such a case is the following:
[0057] When the binary data fetching module receives a non-ATVEF announcement for an update,
it starts a specific task (the code download signaling retriever of figure 2), which
listens to an address specified in the update announcement. The code to be downloaded
is not sent to this address, eventually with other signaling information describing
the download to be carried out. Instead, this address receives a stream which describes
the upcoming download, and in particular a download address. The code download signaling
data retriever task stores this address in a predefined location in the flash memory
8 of the receiver, this location being protected from being erased during the subsequent
download. When the download is to begin, the task reboots the decoder. The loader
7 is then launched. This program fetches the download address from the flash memory
and downloads the code from this address. This update process may also be used in
other environments than that of the present embodiment (i.e. environments not related
to ATVEF).
[0058] Figure 6 is a schematic diagram of a network comprising an emitter 51, and a plurality
of receivers 52i. The emitter comprises a video signal source 53, a data inserter
54 controlled by a broadcast server 61. The broadcast server 61 is connected to a
database 55, containing ATVEF and non-ATVEF data and announcements. The data inserter
inserts data into the VBI lines of the video signal in an appropriate format, under
control of the broadcast server, which defines timing and allocates signal resources.
Data in database 55 may be provided by different sources, in particular a service
provider 56. The broadcast server 61 automatically selects addresses as explained
above, in case such an automatic selection is required. Receivers also comprise a
microprocessor 57, a ROM 58 with a loader program 59 mentioned above, as well as a
register or memory 60 adapted to hold a multicast address during receiver reset and/or
reboot and/or power loss.
[0059] Lastly, although the embodiment above concerns an implementation using the vertical
blanking interval of an analog video signal to transmit the enhancement and update
data, the invention can easily be applied within other system, in particular all-digital
transmission systems.
[0060] The emitter and receiver in the described system both comprises processing means
such as a microprocessor (reference 57 in receivers of figure 5) and memory, for processing
and respectively sending or receiving announcements, triggers, enhancement content
and binary data.
1. Method for transmitting binary data in a video transmission system comprising the
steps of:
- providing announcements of interactive television program enhancement services on
a first predefined IP multicast address;
- providing trigger of interactive television program enhancement services and/or
content transmission on a first range of IP multicast addresses, the method being
characterized by the following steps:
- providing announcements of a receiver software module update on a second predefined
multicast address different from said first address;
- providing receiver software module update data transmission on a second range of
IP multicast addresses, exclusive of the first range.
2. Method according to claim 1, wherein said system comprises an emitter (51) comprising
a data inserter (54) for inserting interactive television program enhancement services
and receiver software module update information into a transmission signal, said method
further comprising the steps of:
- providing announcements of interactive television program enhancement services and
receiver software module update announcements to the data inserter (54),
- dynamic insertion of IP multicast addresses by the data inserter (54) into the announcements,
in accordance with the first and second ranges.
3. Method according to claim 2, further comprising 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 determination by the
data inserter (54), and the fourth range is reserved for addresses which are predefined
in the announcements provided to the data inserter.
4. Method according to one of the claims 1 to 3, wherein ranges are distinguished by
different IP address ranges, different port ranges or both.
5. Method for receiving data in a video transmission system comprising the steps of:
- receiving announcements of interactive television program enhancement services on
a first predefined IP multicast address;
- receiving trigger of interactive television program enhancement services and/or
content transmission on a first range of IP multicast addresses, the method being
characterized by the following steps:
- receiving announcements of a receiver software module update on a second predefined
multicast address different from said first address;
- receiving receiver software module update data transmission on a second range of
IP multicast addresses, exclusive of the first range.
6. Method according to claim 5, comprising, at the level of a receiver, the steps of:
- receiving a receiver software module update announcement announcing transmission
of receiver software module update data, said announcement containing an IP multicast
address (A6) on which signaling data describing the receiver software module update
data transmission is to be sent;
- listening to the address (A6) specified in the announcement;
- retrieving the signaling data and storing it in a memory which is not erased during
download of the receiver software module update data;
- launching of a loader program;
- having the loader program retrieve the stored signaling data; and
- proceeding with the download of the receiver software module update data based on
the stored signaling data.
7. Emitter device (51) for broadcasting announcements in a transmission system compatible
with transmissions of interactive television program enhancement services, said emitter
comprising:
- means for providing announcements of interactive television program enhancement
services on a first predefined IP multicast address;
- means for providing trigger of interactive television program enhancement services
and/or content data on a first range of IP multicast addressee, said emitter being
characterized in that it further comprises:
- means for providing receiver software module update announcements on a second predefined
IP multicast address different from the first predefined address; and
- means for providing receiver software module update data on a second range of IP
multicast addresses, wherein the first and second address ranges are exclusive of
each other.
8. Device according to claim 7, further comprising means (54, 55) for receiving an announcement,
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 announcement.
9. Receiver (52i) for an interactive television program enhancement services compatible
transmission system, said receiver comprising:
- means for receiving announcements of interactive television program enhancement
services on a first predefined multicast address;
- means for receiving trigger of interactive television content enhancement services
and/or content transmission on a first range of IP multicast addresses; said receiver
being characterized in that it further comprises:
- means for receiving receiver software module update announcements on a second predefined
multicast address different from said first address ; and
- means for receiving receiver software module update data transmission on a second
range of IP multicast addresses, exclusive of the first range.
10. Receiver according to claim 9, further comprising a memory (60) 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 (57, 58, 59) for listening to the third multicast address
in the memory after reboot for downloading the binary data from said third multicast
address.
11. Receiver according to claim 10, wherein the third multicast address on which binary
data transmission is announced is provided in signaling data announced on said second
multicast address.
12. Receiver according to claim 11, wherein the downloaded binary file is a complete system
update.
1. Verfahren zum Übertragen von Binärdaten in einem Videoübertragungssystem, wobei das
Verfahren die folgenden Schritte umfasst:
- Liefern von Ankündigungen interaktiver Fernsehprogramm-Erweiterungsdienste an einer
ersten vorgegebenen IP-Gruppenadresse;
- Liefern einer Auslösung interaktiver Fernsehprogramm-Erweiterungsdienste und/oder
einer Inhaltsübertragung an einem ersten Bereich von IP-Gruppenadressen, wobei das
Verfahren durch die folgenden Schritte gekennzeichnet ist:
- Liefern von Ankündigungen einer Empfänger-Softwaremodul-Aktualisierung an einer
zweiten vorgegebenen Gruppenadresse, die von der ersten Adresse verschieden ist;
- Liefern einer Empfänger-Softwaremodul-Aktualisierungsdatenübertragung an einem zweiten
Bereich von IP-Gruppenadressen ausschließlich des ersten Bereichs.
2. Verfahren gemäß Anspruch 1, bei dem das System einen Sender (51) umfasst, der eine
Dateneinfügeeinrichtung (54) zum Einfügen interaktiver Fernsehprogramm-Erweiterungsdienste
und Empfänger-Softwaremodul-Aktualisierungsinformationen in ein Sendesignal umfasst,
wobei das Verfahren ferner die folgenden Schritte umfasst:
- Liefern von Ankündigungen interaktiver Fernsehprogramm-Erweiterungsdienste und Empfänger-Softwaremodul-Aktualisierungsankündigungen
an die Dateneinfügeeinrichtung (54),
- dynamische Einfügung von IP-Gruppenadressen durch die Dateneinfügeeinrichtung (54)
in die Ankündigungen in Übereinstimmung mit dem ersten und mit dem zweiten Bereich.
3. Verfahren gemäß Anspruch 2, das ferner den Schritt des Trennens jeweils des ersten
und/oder des zweiten Bereichs von IP-Gruppenadressen in einen dritten und in einen
vierten Bereich umfasst, wobei der dritte Bereich für die automatische Adressenbestimmung
durch die Dateneinfügeeinrichtung (54) reserviert wird und wobei der vierte Bereich
für Adressen reserviert wird, die in den an die Dateneinfügeeinrichtung gelieferten
Ankündigungen vorgegeben sind.
4. Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem die Bereiche durch unterschiedliche
IP-Adressenbereiche, durch unterschiedliche Portbereiche oder durch beides unterschieden
sind.
5. Verfahren zum Empfangen von Daten in einem Videoübertragungssystem, wobei das Verfahren
die folgenden Schritte umfasst:
- Empfangen von Ankündigungen interaktiver Fernsehprogramm-Erweiterungsdienste an
einer ersten vorgegebenen IP-Gruppenadresse;
- Empfangen einer Auslösung interaktiver Fernsehprogramm-Erweiterungsdienste und/oder
einer Inhaltsübertragung an einem ersten Bereich von IP-Gruppenadressen, wobei das
Verfahren durch die folgenden Schritte gekennzeichnet ist:
- Empfangen von Ankündigungen einer Empfänger-Softwaremodul-Aktualisierung an einer
zweiten vorgegebenen Gruppenadresse, die von der ersten Adresse verschieden ist;
- Empfangen einer Empfänger-Softwaremodul-Aktualisierungsdatenübertragung an einem
zweiten Bereich von IP-Gruppenadressen ausschließlich des ersten Bereichs.
6. Verfahren gemäß Anspruch 5, das auf der Ebene eines Empfängers die folgenden Schritte
umfasst:
- Empfangen einer Empfänger-Softwaremodul-Aktualisierungsankündigung, die die Übertragung
von Empfänger-Softwaremodul-Aktualisierungsdaten ankündigt, wobei die Ankündigung
eine IP-Gruppenadresse (A6) enthält, an der Signalisierungsdaten gesendet werden sollen,
die die Empfänger-Softwaremodul-Aktualisierungsdatenübertragung beschreiben;
- Abhören der in der Ankündigung spezifizierten Adresse (A6);
- Wiedergewinnen und Speichern der Signalisierungsdaten in einem Speicher, der während
des Herunterladens der Empfänger-Softwaremodul-Aktualisierungsdaten nicht gelöscht
wird;
- Starten eines Programmladers;
- Veranlassen, dass der Programmlader die gespeicherten Signalisierungsdaten wiedergewinnt;
und
- Fortfahren mit dem Herunterladen der Empfänger-Softwaremodul-Aktualisierungsdaten
auf der Grundlage der gespeicherten Signalisierungsdaten.
7. Sendervorrichtung (51) zum Rundsenden von Ankündigungen in einem Übertragungssystem,
das mit Übertragungen interaktiver Fernsehprogramm-Erweiterungsdienste kompatibel
ist, wobei der Sender umfasst:
- Mittel zum Liefern von Ankündigungen interaktiver Fernsehprogramm-Erweiterungsdienste
an einer ersten vorgegebenen IP-Gruppenadresse;
- Mittel zum Liefern einer Auslösung interaktiver Fernsehprogramm-Erweiterungsdienste
und/oder von Inhaltsdaten an einem ersten Bereich von IP-Gruppenadressen, wobei der
Sender dadurch gekennzeichnet ist, dass er ferner umfasst:
- Mittel zum Liefern von Empfänger-Softwaremodul-Aktualisierungsankündigungen an einer
zweiten vorgegebenen IP-Gruppenadresse, die von der ersten vorgegebenen Adresse verschieden
ist;
- Mittel zum Liefern von Empfänger-Softwaremodul-Aktualisierungsdaten an einem zweiten
Bereich von IP-Gruppenadressen, wobei der erste und der zweite Adressenbereich einander
ausschließen.
8. Vorrichtung gemäß Anspruch 7, die ferner Mittel (54, 55) zum Empfangen einer Ankündigung
umfasst, um zu bestimmen, ob die Ankündigung eine vorgegebene IP-Gruppenadresse in
einem ersten Bereich umfasst, und im negativen Fall eine IP-Gruppenadresse in einem
zweiten Bereich auszuwählen, der von dem ersten Bereich verschieden ist, und die ausgewählte
IP-Gruppenadresse in die Ankündigung einzufügen.
9. Empfänger (52i) für ein mit interaktiven Fernsehprogramm-Erweiterungsdiensten kompatibles
Übertragungssystem, wobei der Empfänger umfasst:
- Mittel zum Empfangen von Ankündigungen interaktiver Fernsehprogramm-Erweiterungsdienste
an einer ersten vorgegebenen Gruppenadresse;
- Mittel zum Empfangen einer Auslösung interaktiver Fernsehinhalts-Erweiterungsdienste
und/oder einer Inhaltsübertragung an einem ersten Bereich von IP-Gruppenadressen,
wobei der Empfänger dadurch gekennzeichnet ist, dass er ferner umfasst:
- Mittel zum Empfangen von Empfänger-Softwaremodul-Aktualisierungsankündigungen an
einer zweiten vorgegebenen Gruppenadresse, die von der ersten Adresse verschieden
ist; und
- Mittel zum Empfangen einer Empfänger-Softwaremodul-Aktualisierungsdatenübertragung
an einem zweiten Bereich von IP-Gruppenadressen ausschließlich des ersten Bereichs.
10. Empfänger gemäß Anspruch 9, der ferner einen Speicher (60) umfasst, um eine dritte
Gruppenadresse zu empfangen, an der eine Binärdatenübertragung angekündigt wird, wobei
der Speicher derart ist, dass er die Gruppenadresse während eines Empfängerneustartprozesses
aufrecht erhält, wobei der Empfänger ferner Mittel (57, 58, 59) umfasst, um die dritte
Gruppenadresse in dem Speicher nach dem Neustart abzuhören, um die Binärdaten von
der dritten Gruppenadresse herunterzuladen.
11. Empfänger gemäß Anspruch 10, bei dem die dritte Gruppenadresse, an der die Binärdatenübertragung
angekündigt wird, in Signalisierungsdaten geliefert wird, die an der zweiten Gruppenadresse
angekündigt werden.
12. Empfänger gemäß Anspruch 11, bei dem die heruntergeladene Binärdatei eine vollständige
Systemaktualisierung ist.
1. Procédé de transmission de données binaires dans un système de transmission vidéo,
comprenant les étapes suivantes :
- fourniture d'annonces de services interactifs d'amélioration de programme de télévision
sur une première adresse IP de multidiffusion prédéfinie ;
- fourniture d'un déclenchement de services interactifs d'amélioration de programme
de télévision et/ou d'une transmission de contenu sur une première plage d'adresses
IP de multidiffusion, le procédé étant caractérisé par les étapes suivantes :
- fourniture d'annonces d'une mise à jour de module logiciel de réception sur une
deuxième adresse de multidiffusion prédéfinie différente de ladite première adresse
;
- fourniture d'une transmission de données de mise à jour de module logiciel de réception
sur une deuxième plage d'adresses IP de multidiffusion, exclusive par rapport à la
première plage.
2. Procédé selon la revendication 1, dans lequel ledit système comprend un émetteur (51)
comprenant un inséreur de données (54) permettant d'insérer des services interactifs
d'amélioration de programme de télévision et des informations de mise à jour de module
logiciel de réception dans un signal de transmission, ledit procédé comprenant en
outre les étapes suivantes :
- fourniture d'annonces de services interactifs d'amélioration de programme de télévision
et d'annonces de mise à jour de module logiciel de réception à l'inséreur de données
(54),
- insertion dynamique d'adresses IP de multidiffusion par l'inséreur de données (54)
dans les annonces, conformément aux première et deuxième plages.
3. Procédé selon la revendication 2, comprenant en outre l'étape de division de chacune
parmi la première et/ou la deuxième plage d'adresses IP de multidiffusion en une troisième
et une quatrième plage, où la troisième plage est réservée à une détermination automatique
d'adresses par l'inséreur de données (54) et la quatrième plage est réservée à des
adresses qui sont prédéfinies dans les annonces fournies à l'inséreur de données.
4. Procédé selon une des revendications 1 à 3, dans lequel les plages se distinguent
par différentes plages d'adresses IP, différentes plages de ports ou les deux.
5. Procédé de réception de données dans un système de transmission vidéo, comprenant
les étapes suivantes :
- réception d'annonces de services interactifs d'amélioration de programme de télévision
sur une première adresse IP de multidiffusion prédéfinie ;
- réception d'un déclenchement de services interactifs d'amélioration de programme
de télévision et/ou d'une transmission de contenu sur une première plage d'adresses
IP de multidiffusion, le procédé étant caractérisé par les étapes suivantes :
- réception d'annonces d'une mise à jour de module logiciel de réception sur une deuxième
adresse de multidiffusion prédéfinie différente de ladite première adresse ;
- réception d'une transmission de données de mise à jour de module logiciel de réception
sur une deuxième plage d'adresses IP de multidiffusion, exclusive par rapport à la
première plage.
6. Procédé selon la revendication 5, comprenant, au niveau d'un récepteur, les étapes
suivantes :
- réception d'une annonce de mise à jour de module logiciel de réception annonçant
une transmission de données de mise à jour de module logiciel de réception, ladite
annonce contenant une adresse IP de multidiffusion (A6) sur laquelle des données de
signalement décrivant la transmission de données de mise à jour de module logiciel
de réception doivent être envoyées ;
- écoute de l'adresse (A6) spécifiée dans l'annonce ;
- récupération des données de signalement et stockage de celles-ci dans une mémoire
non effacée lors du téléchargement des données de mise à jour de module logiciel de
réception ;
- lancement d'un programme de chargement :
- récupération des données de signalement stockées par le programme de chargement
et
- téléchargement des données de mise à jour de module logiciel de réception en fonction
des données de signalement stockées.
7. Dispositif d'émission (51) permettant de diffuser des annonces dans un système de
transmission compatible avec des transmissions de services interactifs d'amélioration
de programme de télévision, ledit émetteur comprenant :
- un moyen permettant de fournir des annonces de services interactifs d'amélioration
de programme de télévision sur une première adresse IP de multidiffusion prédéfinie
;
- un moyen permettant de fournir un déclenchement de services interactifs d'amélioration
de programme de télévision et/ou des données de contenu sur une première plage d'adresses
IP de multidiffusion, ledit émetteur étant caractérisé en ce qu'il comprend en outre :
- un moyen permettant de fournir des annonces de mise à jour de module logiciel de
réception sur une deuxième adresse IP de multidiffusion prédéfinie différente de la
première adresse prédéfinie et
- un moyen permettant de fournir des données de mise à jour de module logiciel de
réception sur une deuxième plage d'adresses IP de multidiffusion, où les première
et deuxième plages d'adresses sont exclusives l'une de l'autre.
8. Dispositif selon la revendication 7, comprenant en outre un moyen (54, 55) permettant
de recevoir une annonce, déterminer si l'annonce comprend une adresse IP de multidiffusion
prédéterminée dans une première plage, et si ce n'est pas le cas, sélectionner une
adresse IP de multidiffusion dans une deuxième plage, distincte de la première plage,
et insérer l'adresse IP de multidiffusion sélectionnée dans l'annonce.
9. Récepteur (52i) pour un système de transmission compatible avec des services interactifs
d'amélioration de programme de télévision, ledit récepteur comprenant :
- un moyen permettant de recevoir des annonces de services interactifs d'amélioration
de programme de télévision sur une première adresse IP de multidiffusion prédéfinie
;
- un moyen permettant de recevoir un déclenchement de services interactifs d'amélioration
de contenu de télévision et/ou une transmission de contenu sur une première plage
d'adresses IP de multidiffusion, ledit récepteur étant caractérisé en ce qu'il comprend en outre :
- un moyen permettant de recevoir des annonces de mise à jour de module logiciel de
réception sur une deuxième adresse de multidiffusion prédéfinie différente de ladite
première adresse et
- moyen permettant de recevoir une transmission de données de mise à jour de module
logiciel de réception sur une deuxième plage d'adresses IP de multidiffusion, exclusive
par rapport à la première plage.
10. Récepteur selon la revendication 9, comprenant en outre une mémoire (60) permettant
de recevoir une troisième adresse de multidiffusion sur laquelle une transmission
de données binaires est annoncée, ladite mémoire étant conçue de sorte à conserver
l'adresse de multidiffusion lors d'un processus de redémarrage du récepteur, ledit
récepteur comprenant en outre un moyen (57, 58, 59) permettant d'écouter la troisième
adresse de multidiffusion dans la mémoire après un redémarrage pour le téléchargement
des données binaires à partir de ladite troisième adresse de multidiffusion.
11. Récepteur selon la revendication 10, dans lequel la troisième adresse de multidiffusion
sur laquelle une transmission de données binaires est annoncée est fournie dans des
données de signalement annoncées sur ladite deuxième adresse de multidiffusion.
12. Récepteur selon la revendication 11, dans lequel le fichier binaire téléchargé constitue
une mise à jour complète du système.