DESCRIPTION
ANNOUNCING APPLICATIONS IN A DIGITAL BROADCASTING SYSTEM
This invention relates to announcing applications in a digital broadcasting system.
Digital Video Broadcasting (DVB) systems are well-established and are used to transmit audio and video content to receivers. Such systems can also be used to deliver applications such as electronic programme guides (EPG), games, quizzes, instructional guides and e-commerce applications such as home banking. Conventionally, information about available applications is announced to terminals in the form of an Application Information Table (AIT) which is broadcast as part of a transport stream. The Application Information Table specifies the location of the files for each application. A receiver locates the AIT within the transport stream and presents a user with the available applications. If a user requests a particular application, the receiver downloads each of the files relating to the application from the broadcast stream and executes the code to run the application. There is now interest in providing Digital Video Broadcasting receivers which can access the Internet as well as broadcast streams. One variant of the Digital Video Broadcasting Multimedia Home Platform (DVB-MHP) provides internet access and is described in ETSI TS 102 812 (Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1). Chapter 9.8.3 of this document states that a user can enter a URL from which the terminal can download an AIT, i.e. the AIT is hosted by a network server. This has several disadvantages, including the need for the terminal to periodically monitor the URL for any changes to the AIT, and the associated burden on the server hosting the URL.
The present invention seeks to provide an improved way of announcing applications to terminals.
Accordingly, a first aspect of the present invention provides a method of announcing the availability of an application to a terminal of a digital broadcasting system, comprising: preparing an announcement message which includes at least part of an Application Information Table (AIT), the AIT including information about available applications and storage locations of the files required for the applications; and, sending the announcement message to a multicast network address which can be accessed by the terminals. Once terminals have joined the multicast group defined by the multicast address they can listen to all announcements sent to that address. Any updates to the AIT will automatically be sent ('pushed') to the terminals in the multicast group. There is no need for the terminal to periodically contact a server which hosts the AIT. When a large number (possibly several millions) of terminals are deployed in an area and the terminals each need to contact a server on a periodic basis for updated AIT data, this generates a significant volume of traffic which can overload the server. Even if the server is not overloaded, the considerable volume of traffic can incur a significant cost to the company hosting the server. Different service providers (e.g. broadcasters or application providers) can easily send announcements to the same multicast address. This contrasts with hosting an AIT on a server, where the server is usually owned by a single company and is difficult for multiple parties to update. The multicast network address can be an address which receives announcements for general multicast multimedia sessions, such as video streams. By sending the AIT announcement messages to the same address as the multimedia announcements, the terminal need only 'listen' to one address for all media and application related announcements.
Conveniently, the AIT is sent in the same form as announcements of multimedia sessions. The AIT is sent as part of Session Announcement Protocol (SAP) message, with the AIT packaged into the payload of a SAP message. A large AIT may need to be split into sections and divided across several SAP messages, although these can be readily associated with one another by arranging for each message to carry an identifier which indicates what section is carried by that message. The total number of sections can also be indicated. Preferably, this sectioning is achieved using the same sectioning mechanisms that are used for large broadcast AITs. The invention can be applied to transmitting the AIT for broadcasting formats such as DVB-MHP. Another aspect of the invention provides a signal for transmission across a network comprising a multimedia session announcement message which includes at least part of an Application Information Table (AIT), the AIT including information about available applications and storage locations of the files required for the applications. A further aspect of the invention provides a controller for a terminal of a digital broadcasting system, the terminal having a network connection, the controller being operable to: join a multicast group; and, retrieve an Application Information Table (AIT) carried in an announcement message sent to the multicast group, the AIT including information about available applications and storage locations of the files required for the applications. The functionality described here can be implemented in software, hardware or a combination of these. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. Accordingly, another aspect of the invention provides software for implementing the method. It will be appreciated that software may be installed on the terminal, or a network entity at any point during the life of the equipment. The software may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium. The software may be delivered as a
computer program product on a machine-readable carrier or it may be downloaded directly to the host device via a network connection.
Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:- Figure 1 shows a digital broadcasting system; Figure 2 shows the format of a Session Announcement Protocol (SAP) message; Figure 3 shows the functional blocks within a terminal of the system shown in Figure 1.
Figure 1 shows a digital video broadcasting system for delivering content to terminals at user premises 100, one of which is shown in Figure 1. Content is generated by a broadcaster 30. The content can take the form of live feeds of audio and video content, such as live television and radio programmes, and content which has been previously recorded and stored. Content is coded into an appropriate format, such as MPEG-2 audio and video as set out in ISO/TEC 13818-2 and ISO/IEC 13818-3. A broadcaster generates one or more transport streams, each carrying multiple channels of audio and video content and a data carousel. The transport streams are broadcast over delivery channel 35 to user premises. Video and audio services can also be delivered to suitably-equipped terminals by multicasting over a network such as the Internet 80. Services are announced using the Session Announcement Protocol (SAP) to an address 85 which is known by interested terminals 60. One example of such a multicast address is IP address 224.2.127.254 on port 9875. Session Description Protocol (SDP) data is carried within the SAP message and provides details of the multicast services. The Session Description Protocol (SDP) is described in RFC2327. Terminals join the multicast group defined by this multicast address and receive SAP announcements. If a user wishes to join one of the services defined by the SAP/SDP messages, their terminal requests to join the multicast group specified in one of the SAP/SDP messages and will then
receive streamed data for the service across network 80. A DVB-MHP terminal which can access the Internet and which uses the Session Announcement Protocol (SAP) to access video streams is further described in WO 03/056828. The system shown in Figure 1 also provides interactive applications, such as electronic programme guides (EPG), games, quizzes, instructional guides and e-commerce applications such as home banking. Applications can be carried by one of transport streams that are broadcast 35 to terminals. Broadcaster 30 transmits an Application Information Table (AIT) as part of the transport stream. The AIT lists available applications and instructs the terminal where to find the files for each application, which is typically elsewhere in the transport stream. A formatting function 34 within broadcaster 30, or at some other convenient point in the distribution chain, gathers the information required for the AIT and formats the AIT into the required form for transmission as part of the transport stream. In accordance with the invention, formatting function 34 formats the AIT for distribution to network 80. Conveniently, the AIT is sent in the same form as the announcements of multimedia sessions described above. Figure 2 shows a SAP message 300. The Session Announcement Protocol (SAP) is more fully described in RFC2974. A SAP message includes a header portion 310 and a payload portion 320. The header 310 has fields 301 specifying various parameters, including a Message Identifier Hash, a field 302 carrying an IP address which identifies the originating source and an optional field 303 carrying authentication data. Field 304 identifies the payload type. This will indicate that the payload is an AIT, and can be set to the mime type of the AIT (e.g. "application/ait"). The payload 320 of the SAP message 300 normally carries SDP information in text form. However, in this case the SAP message carries an AIT, in binary form, in payload 320. It is also possible, but less preferable, to carry a textual description of the AIT (e.g. as an XML file). RFC2974 recommends that SAP packets are smaller than IkByte in size. A large AIT which would cause the SAP packet to exceed this size can
either be sent in its entirety or, more preferably, it can be split into a number of sections and divided across several SAP messages. Assuming there are m sections in total, each section of the AIT includes an identifier field 305 to indicate that it is section n out of a total of m sections (where n<m). This allows a terminal 60 to readily identify how many sections the AIT is divided into, and which sections it has, or still requires. There is an established way of indicating this sectioning information within an AIT, which is used for broadcast AITs that are divided into sections, and so there is no need to modify the format of the AIT. Preferably, each section of the AIT is less than IkByte in size, to conform to RFC2974. The SAP message is carried inside a UDP packet which is addressed to the multicast address. The SAP message carrying the AIT is sent to the multicast network address 85. The multicast address 85 is shown in Figure 1 as a single point but it will, of course, represent a group of routers and terminals. Terminals 60 which are connected to network 80, and which joined the multicast group defined by this multicast address, can listen to announcement messages that are sent to address 85. Once a terminal receives an announcement message which it recognises as carrying an AIT, it parses the code and presents a list of available applications to a user, such as in the form of a menu on display 12. If the terminal recognises that the message contains only one section of an
AIT it waits until it has received all of the sections. When a user selects a particular application terminal 60 refers again to the AIT (now locally stored) which lists the storage locations of the files required by the selected application. The files can be stored 32 at the broadcaster or at another network location 50. The required files are retrieved 81 , 82 and executed by terminal 60 to run the requested application. The announcement message carrying the AIT is transmitted periodically to multicast address 85. RFC2974 (SAP) describes the announcement interval at section 3.1. Referring to Figures 1 and 3, terminal 60 at a user premises receives the broadcast signal, which in this embodiment is via an antenna 18. Terminal 60 also includes a user interface with a remote control 20 or keyboard for receiving user inputs 22 and a graphical output for displaying messages which
can be overlaid upon the video signal 10 which is fed to television display 12. Terminal 60 also includes an interface/modem 72 for accessing the Internet Protocol (IP) based network 80. Figure 3 shows the functional blocks within terminal 60. In a known manner, terminal 60 includes a front end for processing a received broadcast signal 35. This includes a tuner and demodulator 61 for selecting and demodulating a required channel and an optional conditional access unit 62 for descrambling the signal. The resulting digital data stream is demultiplexed 63 into data streams representing audio and video data (typically in MPEG-2 format) and data for applications in the form of the repetitively broadcast DSM- CC Object Carousel 64. The audio and video data can then be further processed 65 to derive suitable output signals 10, 14 for presentation to a user. Once downloaded from the broadcast stream, the application (or several applications) will reside on a storage device in the terminal and will be executed by microprocessor 68. Control software for operating the terminal 60 also resides on storage device 69. It should be noted the terminal shown in Figure 3 can receive signals via a broadcast delivery channel 35 as well as accessing internet 80. In another embodiment, terminal 60 is connected only to the Internet 80 and only receives streamed video and audio material via an IP-based delivery channel. Storage device 69 includes instructions which cause the processor 68 to listen to the network address 85 to which multimedia session announcements are usually sent. It is preferred that a default network address is stored in the terminal at the time of purchase. However, a user can change the address, or add new addresses, by using the user interface 22. It is also possible for a program received via the broadcast stream to cause the processor to store a new network address. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words "comprising" and "including" do not exclude the presence of other elements or
steps than those listed in the claim. Where the system/device/apparatus claims recite several means, several of these means can be embodied by one and the same item of hardware. In the description above, and with reference to the Figures, there is described a digital broadcasting system in which terminals 60 can execute applications. An Application Information Table (AIT) includes information about available applications and storage locations of the files required for the applications. An AIT is carried by an announcement message which is sent to a multicast network address. Announcement messages can use the Session Announcement Protocol (SAP) which is ordinarily used to announce multimedia sessions. Terminals join the multicast group and then receive all announcements sent to the multicast address. A large AIT is split into sections and carried by multiple SAP messages. Each message includes an identifier of the section carried by that message. In order to run an application, terminal 60 retrieves 81, 82 files from network locations specified in the AIT.