WO2009034512A2

WO2009034512A2 - Referencing out-of-band notification objects in dvb-ipdc

Info

Publication number: WO2009034512A2
Application number: PCT/IB2008/053620
Authority: WO
Inventors: Jozef P. Van Gassel
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2007-09-14
Filing date: 2008-09-08
Publication date: 2009-03-19
Also published as: WO2009034512A3

Abstract

In a Digital Video Broadcasting Internet Protocol Datacast (DVB-IPDC) system, a Notification message (60) carries an indirect reference (61) to alocation (63) of an out-of-band Notification data object(65). The out-of-band Notification data object(65) is transmitted out-of-band as part of a transmission session (63). Mapping data (44) is provided which a terminal can use to map the indirect reference (61) to thelocation (63) from which the out-of-band Notification data object(65) can be retrieved.The Notification message (60) also carries a reference(62) which identifies the particular transport object within the transmission session (63) that carries the out-of-band Notification data object(65). The indirect reference (61) can be of a relatively small size, smaller than a direct reference to the location (63) of the notification data object. The mapping data can be transmitted in a manner which identifies it as being data which needs to be loaded as part of a bootstrapping process ofthe terminal.

Description

Referencing out-of-band notification objects in DVB-IPDC

FIELD OF THE INVENTION

This invention relates to Digital Video Broadcasting - Internet Protocol Datacast (DVB-IPDC).

BACKGROUND TO THE INVENTION

Digital Video Broadcasting for IP Datacasting (DVB-IPDC) defines a set of systems layer specifications for DVB mobile TV systems. DVB-IPDC can be applied to Digital Video Broadcasting for Handheld Terminals (DVB-H), which is an emerging standard for delivering digital TV to handheld devices such as mobile telephones and Personal Digital Assistants (PDAs).

One aspect of DVB-IPDC is Notification. A Notification is used by the network to provide information about forthcoming events. These events can be related to services and contain information which is delivered from the network to the terminal (or end- user). Examples of Notification services are score updates in sports broadcasts, stock tickers and news services. Notifications are not necessarily user-oriented. Examples of system- oriented notifications are, for example, signalling of important software updates or changes in the Electronic Service Guide (ESG).

Notification messages can take the form of a first message part, called a notification trigger message, which carries a reference to a second message part. The second message part comprises a notification payload and is transmitted out-of-band. "Out-of-band" generally means some other transport location other than the first message part such as, for example, a different file delivery session. This is particularly useful where the payload is large, such as a large file, e.g. a software update.

It is desirable that each instance of a Notification occupies as little of the transmission bandwidth as possible, especially as Notifications may need to be transmitted multiple times. There are various reasons why Notifications may need to be sent multiple times. As a broadcast network lacks a return channel, and therefore lacks a mechanism to ensure all terminals receive the Notification, it is advisable to send each Notification multiple times. Also, an object referred to which a Notification relates may have a sequence of phases (a life cycle) which individually need to be notified to terminals.

The present invention seeks to provide a more efficient way of delivering Notification messages and, in particular, a more efficient way of delivering Notification messages which refer to out-of-band Notification objects.

SUMMARY OF THE INVENTION

A first aspect of the present invention provides a method of transmitting Notifications in a Digital Video Broadcasting - Internet Protocol Datacast (DVB-IPDC) system, comprising: transmitting a Notification message which carries an indirect reference to a location of an out-of-band Notification data object; transmitting the out-of-band Notification data object; and, transmitting mapping data which a terminal can use to map the indirect reference to the location from which the out-of-band Notification data object can be retrieved.

An advantage of this aspect of the invention is that the indirect reference carried within the Notification message can be of a relatively small size, and certainly much smaller than a direct reference to the location of the notification data object, such as a full Session Description Protocol (SDP) description which would typically amount to 500 bytes in size. This can provide a large increase in Notification message overhead efficiency and a large reduction in bandwidth used by the Notification messages, especially when it is considered how each Notification message may be transmitted multiple times. Minimising the size of each Notification message also helps to avoid the risk of exceeding the Maximum Transmission Unit (MTU) size of packets, which avoids the need to perform fragmentation at some level in the protocol stack. Advantageously, the out-of-band Notification data object is carried within a transmission session, the indirect reference comprises a Uniform Resource Identifier and the mapping data comprises a mapping between the Uniform Resource Identifier carried within the Notification message and a Session Description Protocol file which identifies the transmission session.

Preferably, the out-of-band Notification data object is carried within a transmission session and the Notification message further carries an object-identifying reference, such as a Uniform Resource Identifier, to identify the out-of-band Notification data object within the transmission session. The mapping data can be made available to terminals in various ways. A particularly advantageous way of making the mapping data available is by transmitting the mapping data in a manner which identifies the mapping data as being data which needs to be loaded as part of a bootstrapping process of the terminal, or some other start-up process. This can be achieved by selection of an appropriate descriptor, and the level at which this descriptor is introduced. A common set of mapping data can be transmitted across an Internet Protocol (IP) platform or a set of (different) mapping data can be transmitted for each Electronic Service Guide provider. This can be achieved by selection of an appropriate descriptor, and the level at which this descriptor is introduced. Preferably there is a substantially static mapping between Notification messages and out-of-band storage locations of Notification data objects, even though the content of Notifications will change dynamically. This can help to ensure that the mapping data need only be retrieved by a terminal on an infrequent basis, such as once upon each start-up, which helps to save energy resources at the terminal. A further aspect of the invention provide a network entity arranged to perform any of the steps of this method.

A further aspect of the invention provides a method of processing Notification objects at a terminal in a Digital Video Broadcasting - Internet Protocol Datacast (DVB- IPDC) system, comprising: - receiving mapping data; receiving a Notification message which carries an indirect reference to a location of an out-of-band Notification object; using the mapping data to map the indirect reference in the Notification message to the location of the out-of-band Notification object; - receiving the out-of-band Notification object from the location indicated by the mapping data.

Further aspects of the invention provide a terminal arranged to perform this method.

A further aspect of the invention provides a signal for transmission in a Digital Video Broadcasting - Internet Protocol Datacast (DVB-IPDC) system, comprising: a Notification message which carries an indirect reference to a location of an out-of-band notification data object; an out-of-band Notification data object; and, mapping data which a terminal can use to map the indirect reference to the location from which the out-of-band Notification data object can be retrieved.

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. The term

"computer" is intended to encompass any electronic processing apparatus which includes, but is not limited to, a microprocessor, a microcontroller, a programmable logic device, a ( re- )confϊgurable processing array, a programmable gate array and a digital signal processor. Accordingly, another aspect of the invention provides software for implementing the method. 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 to the terminal or network entity via a network connection.

The features of the present invention can be applied to Digital Video Broadcasting for IP Datacasting (DVB-IPDC) over Digital Video Broadcasting for Handheld Terminals (DVB-H), as well as other current and future DVB standards, such as DVB-SH.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 shows an embodiment of invention implemented in a DVB-H transmission system;

Fig. 2 shows the process of mapping a reference in a Notification message to an out-of-band payload using a look-up table.

DESCRIPTION OF PREFERRED EMBODIMENTS

Figure 1 shows a generalised system for providing IP Datacast over a DVB-H transmission system, as described in ETSI TR 102 469 vl.1.1 (2006-05). Figure 1 also shows additional elements to perform the present invention. A Service Application/Service Management entity 10 aggregates content from various content sources, such as audio, video and data content and generates IP packets carrying the various services which are to be offered to terminals. An Electronic Service Guide is created, based on metadata describing the content which is offered. A broadcast network 20 includes a multi-protocol encapsulation (MPE) process which encapsulates the IP packets into MPE-sections. Forward error correction is applied to the MPE sections and MPE sections are assigned to time slices. The output of the IP-encapsulator 21 is applied to a DVB modulator 22, which applies Orthogonal Frequency Division Multiplexing (OFDM) to the data. OFDM modulated data is wirelessly transmitted over a channel 30. At a DVB-H terminal 40, received signals are applied to a DVB-T demodulator 41 and a DVB-H IP-decapsulator 42. Further detail of the operation of these conventional entities can be found in section 4.2 of ETSI TR 102 469 vl.1.1 (2006-05) and an overview is provided in the article "DVB-H: Digital Broadcast Services to Handheld Devices", G. Faria, J. A. Henriksson, E. Stare, and P. Talmola, Proc. IEEE, vol. 94, no. 1, pp. 194-209, Jan. 2006. The process of Notification will now be described. A Notification message can be transmitted over a channel of the DVB system. Notification messages can be one of two general types. A first type of notification message is essentially self-contained, and carries a payload of data along with the notification message. For example, a notification message of a sports score can carry the text of the score as part of the notification message. A second form of notification message comprises two parts. A first message part, called a notification trigger message, carries information about the notification and carries a reference to a second message part. The second message part comprises a notification payload and is transmitted out-of-band. "Out-of-band" generally means some other transport location such as, for example a different file delivery session. This second type of notification is particularly useful where the payload is large, such as a notification message notifying a terminal of a software update. This invention concerns notification messages of this second type.

The Service Application/Service Management entity 10 has a Notification generation function 11 which generates Notification messages. Notification messages may be generated in response to external events, such as sports scores, news stories, the availability of software updates and so on. Notification generation function 11 can create a two-part notification comprising a trigger Notification message and a payload which is to be associated with that Notification message. A trigger Notification message includes a short reference - a Uniform Resource Identifier (URI) - which provides an indirect reference to the out-of-band location of the payload associated with the message. The Service Application/Service Management entity 10 also has a function 12 which generates mapping data. The mapping data maps the relationship between the short reference (URI) carried within a message and the location of the payload. The mapping data for multiple Notification messages can be sent together as a look-up table. An example of the look-up table can be illustrated as follows:

The indirect reference (URI) carried within the notification trigger message can be relatively short, whereas the full location of the out-of-band payload can be defined by a much longer reference (an SDP file) with no loss in bandwidth efficiency on the notification transport link.

The mapping data is transmitted to broadcast network 20 for use by terminals 40. At a terminal 40, a Notification processing function 43 extracts the mapping data 44 and stores the mapping data 44 locally at the terminal. Notification processing function 43 also receives Notification messages and, when a trigger Notification message is received, uses the mapping data to determine the location of the out-of-band payload associated with the trigger Notification message.

The process of resolving an out-of-band notification object 65 from a notification message 60 is illustrated in Figure 2. An example trigger Notification message 60 is shown. Out-of-band payloads can be delivered using File delivery over Unidirectional Transport (FLUTE) sessions as defined in RFC 3926. Trigger Notification message 60 carries a short URI 61 which indirectly refers to the particular FLUTE session that carries the target out-of-band Notification object 65. URI 61 is called an SDP URI as it refers to an entry in a table 44 which can resolve the URI to an SDP file which defines the FLUTE session. Mapping data 44 stored at a terminal 40 defines a mapping between each SDP URI and the location of the FLUTE session which carries the out-of-band Notification object 65 corresponding to the Notification message. In this example, SDP URI2 maps to SDP2, which identifies FLUTE SESSION 2 63. Trigger Notification message 60 also carries a second URI 62 which points to an item within the FLUTE session 63. This second URI 62 is called an OBJ URI as it points to an object. A FLUTE session carries a File Descriptor Table 64 which defines a mapping between Content-location URIs and Transport Object Identifiers (TOIs). The FDT is used to map the OBJ URI 62 to the particular TOI, and hence object, within the FLUTE session. In this example, the FDT 64 of FLUTE SESSION 2 maps OBJJJRB to TOB, which is the target out-of-band object 65. The FDT 64 for FLUTE- SESSION 2 is shown in more detail in the top right-hand corner of Figure 2.

The trigger Notification message 60 can be carried over FLUTE, Real-time Transport Protocol (RTP), or some other delivery mechanism. Preferably, the mapping data 44 is continuously broadcast as part of the filing carousel. This allows a terminal to quickly acquire the mapping data 44 upon start-up. The Notification messages 60 can be broadcast as necessary, and the out-of-band Notification objects 65 can be repetitively broadcast as part of the FLUTE filing carousel. It is envisaged that the mapping data 44 will vary on a relatively slow timescale while the Notification messages and out-of-band Notification objects 65 can vary on a much shorter timescale.

Options for transmitting the mapping data, and for acquiring the mapping data at a terminal, are described in more detail below. It may be possible for a terminal to acquire the mapping data on a single occasion, at terminal start-up or even less frequently as part of a process of scanning for information about new services. This is because although Notifications may carry new data, a Service Provider/Service Management entity will typically define a particular place where each type of Notification message will be transmitted. For example, all two-part Notification messages concerning news items will store payloads at location ABC, all software updates will store payloads at location DEF. Thus, it can be seen that the mapping between a Notification message and an out-of-band payload is static, even though the contents of the message and payload are dynamic. Clearly, the less frequently that a terminal needs to acquire new mapping data, the more power efficient a terminal becomes.

One option for transmitting the mapping data is to carry the additional table (implicitly) by introducing a special SDP Notification Stream. Effectively, this is implemented using a regular FLUTE Session. This SDP Stream can either be dedicated for this purpose or a FLUTE session can be used for other purposes as well (e.g. carrying ESG information). The actual look-up mechanism can conveniently be achieved through use of the File Descriptor Table (FDT) of the FLUTE (RFC 3926) protocol as will now be explained. In FLUTE a File Descriptor Table (FDT) is used to provide a mapping between transport objects (i.e. files) and URIs which can be used to refer to the individual transport objects. In other words, it provides a mapping between objects, identified by a Transport Object Identifier (TOI) and Content-Location URIs. The FDT of a FLUTE stream is used to relate URIs to SDP files, so the Content-Location URIs of the FDT are the URIs 61 and the transport objects carried in the session are the actual SDP files. In this way, a simple look-up mechanism is established by inspecting the FDT and resolving the location of the corresponding SDP information. Using this scheme, the referring Notification message 60 only needs to carry the short URI 61 instead of the relatively long content of the SDP file.

There is a need to identify the location of this mapping data 44 to terminals. Advantageously, the special FLUTE session which carries this mapping data should be discoverable during the bootstrapping process of the terminal. For these purpose special extensions to the bootstrap mechanism are proposed.

The main element describing the location of the special Notification SDP Stream may follow the following syntax.

The IP Source address, IP Destination address, port number and Transport Session Identifier (TSI) are sufficient to describe the location of such a special Notification SDP Session. Depending on whether the IP Platform uses IPv4 or IPv6 addresses different numbers of bits are allocated for the IP addresses in the descriptor. Note that the mnemonics in the above table are: uimsbf = unsigned integer, most significant bit first; bslbf = bit string, left bit first. It will be appreciated that the above table is an example syntax and that the precise syntax can vary from that shown

The scope of the Notification SDP Stream syntax element

(NotificationSDPStreamEntry) as depicted in the table above can be at two different levels: 1. At the IP Platform level, this is particularly useful if the Notification SDP

Stream is used for Platform Default Notification (PDN) messages or if the sessions are re- used by multiple ESG providers (although the same Notification SDP Stream could also be announced within multiple ESG Providers).

2. At the ESG Provider level, in case the scope of the Notification SDP Stream is limited to a particular ESG Provider (which is usually the case for user oriented notification messages). Especially for user-oriented Notification services this is a likely option.

There are needs for Notification messages at the platform and ESG Provider level depending on the particular situation/use case.

The integration of the syntax element (NotificationSDPStreamEntry) can be achieved at a number of different levels of the Notification bootstrapping mechanism as it is currently defined in the draft specification (i.e. TM-CBM 1943r2):

1. At the ESG Bootstrapping level, a) As a separate top-level bootstrap descriptor (i.e. a separate file in the bootstrap

FLUTE session). b) Merged with the DefaultNotificationAccessDescriptor (as defined in TM-

CBM 1943r2).

2. At the ESG level, in this case the Notification SDP stream is discovered through the ESG itself.

Embodiments for options Ia, Ib and 2 are explained more fully below. Option

Ib is the most preferable solution as it does not require a new descriptor and the Notification SDP Stream is defined at the global level, which is not the case for the ESG approach).

New top-level descriptor (option Ia) In this case a second NotifϊcationSDPStreamDescriptor bootstrap descriptor is introduced specifically for providing access to the Notification SDP stream. The syntax of this descriptor can be as follows:

Merged Approach (option Ib)

In this case the already defined DefaultNotifϊcationAccessDescriptor is combined with the new NotificationSDPStreamDescriptor descriptor defined earlier in this document into a single top-level NotificationAccessDescriptor carried in the bootstrap FLUTE session. The syntax of this descriptor can be as follows:

It should be noted for both cases Ia and Ib that the same solution can be described in slightly different ways using pseudo code function decomposition.

ESG Data Model (option 2)

In this case the Notification SDP Stream is defined at the XML level in the ESG Data Model. This can be achieved by extending the SessionDescription element which is a child element of the AcquisitionFragment element. In particular the

ComponentCharacteristic element can be extended to describe the Trigger Notification stream and the Notification Object (i.e. payload) stream. However it should be noted that the Notification SDP Stream can be global to the entire ESG and this would lead to repetition of the same information throughout the complete ESG for every Notification service. Defining it at the global ESG level would require a significant extension of the ESG Data Model. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practising the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope.

Claims

CLAIMS:

1. A method of transmitting Notifications in a Digital Video Broadcasting -

Internet Protocol Datacast (DVB-IPDC) system, comprising: transmitting a Notification message which carries an indirect reference to a location of an out-of-band Notification data object; - transmitting the out-of-band Notification data object; and, transmitting mapping data which a terminal can use to map the indirect reference to the location from which the out-of-band Notification data object can be retrieved.

2. A method according to claim 1 wherein the out-of-band Notification data object is carried within a transmission session and wherein the Notification message also carries an object-identifying reference to identify the out-of-band Notification data object within the transmission session.

3. A method according to claim 2 wherein the Notification message carries a

Uniform Resource Identifier to identify the out-of-band Notification data object within the transmission session.

4. A method according to any one of the preceding claims wherein the mapping data is transmitted with an identity of a type which indicates that it should be loaded as part of a bootstrapping process of the terminal.

5. A method according to any one of claims 1 to 3 wherein the mapping data is transmitted with an identity of a type which indicates that it should be loaded as part of the Electronic Service Guide.

6. A method according to any one of the preceding claims wherein the indirect reference has a length of less than 100 bytes.

7. A method according to any one of the preceding claims wherein multiple items of mapping data are transmitted together.

8. A method according to any one of the preceding claims wherein the out-of- band Notification data object is carried within a transmission session, the indirect reference comprises a Uniform Resource Identifier and the mapping data comprises a mapping between the Uniform Resource Identifier carried within the Notification message and a Session Description Protocol file which identifies the transmission session.

9. A method according to claim 8 wherein the mapping data is transmitted using a FLUTE session and a File Descriptor Table (FDT) of the FLUTE session relates Uniform Resource Identifiers to Session Description Protocol files.

10. A method according to any one of the preceding claims wherein a common set of mapping data is transmitted across an Internet Protocol (IP) platform.

11. A method according to any one of the preceding claims wherein a set of mapping data is transmitted for each Electronic Service Guide provider.

12. A method of processing Notification objects at a terminal in a Digital Video

Broadcasting - Internet Protocol Datacast (DVB-IPDC) system, comprising: receiving mapping data; receiving a Notification message which carries an indirect reference to a location of an out-of-band Notification object; - using the mapping data to map the indirect reference in the Notification message to the location of the out-of-band Notification object; receiving the out-of-band Notification object from the location indicated by the mapping data.

13. A method according to claim 12 wherein the mapping data is transmitted with an identity of a type which indicates that it should be loaded as part of a bootstrapping process of the terminal, and the method further comprises receiving the mapping data as part of the bootstrapping process of the terminal.

14. A method according to claim 12 or 13 wherein the out-of-band Notification data object is carried within a transmission session and the mapping data identifies the transmission session, and wherein the Notification message also carries an object-identifying reference to identify the out-of-band Notification data object within the transmission session and the method further comprises using the object-identifying reference to receive the Notification object.

15 A network entity arranged to perform the method according to any one of claims 1 to 11.

16. A terminal for use in receiving Digital Video Broadcasting - Internet Protocol

Datacast (DVB-IPDC) signals which is arranged to perform the method according to any one of claims 12 to 14.

17. Software which, when executed by a computer, causes a network entity to perform the method of any one of claims 1 to 11 or causes a terminal to perform the method of any one of claims 12 to 14.

18. A signal for transmission in a Digital Video Broadcasting - Internet Protocol Datacast (DVB-IPDC) system, comprising: a Notification message which carries an indirect reference to a location of an out-of-band notification data object; an out-of-band Notification data object; and, mapping data which a terminal can use to map the indirect reference to the location from which the out-of-band Notification data object can be retrieved.