Institutionen fr systemteknik

Department of Electrical Engineering

Examensarbete

Investigation and implementation of the OMA BCAST Service Interaction Function

Examensarbete utfrt i Datatransmission vid Tekniska hgskolan i Linkping av Karl-Johan Lundkvist LiTH-ISY-EX--07/3979--SE
Linkping 2007

Department of Electrical Engineering Linkpings universitet SE-581 83 Linkping, Sweden

Linkpings tekniska hgskola Linkpings universitet 581 83 Linkping

Investigation and implementation of the OMA BCAST Service Interaction Function

Examensarbete utfrt i Datatransmission vid Tekniska hgskolan i Linkping av

Karl-Johan Lundkvist LiTH-ISY-EX--07/3979--SE

Handledare: Examinator:

Iftikhar Waheed
Ericsson AB

Danyo Danev
isy, Linkpings universitet

Linkping, 22 May, 2007

Avdelning, Institution Division, Department Division of Telecommunications Department of Electrical Engineering Linkpings universitet S-581 83 Linkping, Sweden Sprk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats vrig rapport ISBN ISRN

Datum Date

2007-05-22

LiTH-ISY-EX--07/3979--SE Serietitel och serienummer ISSN Title of series, numbering

URL fr elektronisk version http://www.ep.liu.se

Titel Title

Underskning och implementation av OMA BCAST Service Interaction Function Investigation and implementation of the OMA BCAST Service Interaction Function

Frfattare Karl-Johan Lundkvist Author

Sammanfattning Abstract This thesis is a study of a new specication for end user interactivity developed by the Open Mobile Alliance, the specication is called OMA BCAST Service Interaction Function. The specication is one part of the OMA BCAST Service Enabler, which enables service delivery to mobile devices, where the most common service is mobile television. The Service Interaction Function enables end user interactivity related to a service, this could be a poll about the current television program or a chat where every message is presented to the users that are watching the same channel. The specication is still of draft version and the scope of this thesis has been to investigate the Service Interaction Function and implement a PC prototype.

Nyckelord Keywords Data broadcast, mobile television, digital television, end user interactivity

Abstract
This thesis is a study of a new specication for end user interactivity developed by the Open Mobile Alliance, the specication is called OMA BCAST Service Interaction Function. The specication is one part of the OMA BCAST Service Enabler, which enables service delivery to mobile devices, where the most common service is mobile television. The Service Interaction Function enables end user interactivity related to a service, this could be a poll about the current television program or a chat where every message is presented to the users that are watching the same channel. The specication is still of draft version and the scope of this thesis has been to investigate the Service Interaction Function and implement a PC prototype.

Acknowledgements
I would like to thank Mr Iftikhar Waheed, my supervisor at Ericsson for help and support during the work. I would also like to thank my family for their unconditional support throughout the thesis work.

vii

ix

Abbreviations
Abbreviation AAC ALC API ASM ATSC BML COFDM CSS DiBEG DVB-H DVB-T DTTB EPG ESG FEC FDT FLUTE GERAN GZIP HDTV IETF IMD IPDC IPSec IPTV ISDB ITU LDTV MBMS MMS OFDM OMA OMA BCAST QAM QPSK SDTV SMS SSM STB SVG UDP UHF Explanation Advanced Audio Coding Asynchronous Layered Coding Application Programming Interface Any-Source Multicast Advanced Television Systems Committee Broadcast Markup Language Coded Orthogonal Frequency-Division Multiplexing Cascading Style Sheet Digital Broadcasting Experts Group Digital Video Broadcasting - Handheld Digital Video Broadcasting - Terrestrial Digital Terrestrial Television Broadcast Electronic Program Guide Electronic Service Guide Forward Error Correction File Delivery Table File Delivery over Unidirectional Transport GSM EDGE Radio Access Network GNU ZIP High denition Television The Internet Engineering Task Force Interactivity Media Document IP Datacast IP Security Internet Protocol Television Integrated Services Digital Broadcasting International Telecommunication Union Low Denition Television Mobile Broadcast/Multicast Service Multimedia Messaging Service Orthogonal Frequency Division Multiplexing Open Mobile Alliance OMA Broadcast, a working group within OMA that examine the need of Mobile Broadcast Services Quadrature Amplitude Modulation Quadrature Phase-Shift Keying Standard Denition Television Short Message Service Source-Specic Multicast Set-Top Box Scalar Vector Grapics User Datagram Protocol Ultra High Frequency

xi Abbreviation UMTS UTRAN VHF VOD VSB WAP XML Explanation Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network Very High Frequency Video On Demand Vestigial Side Band Wireless Application Protocol eXtensive Markup Language

Contents
1 Introduction 1.1 Background . . . . . 1.2 Purpose . . . . . . . 1.3 Problem description 1.4 Method . . . . . . . 1.5 Limitations . . . . . 1.6 Outline . . . . . . . 1 1 2 3 3 4 4

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Theoretical Background
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
9 9 9 11 12 13 15 17 17 17 18 19 19 20 22

2 IP Datacasting 2.1 Digital Television . . . . . . . . . . . 2.1.1 IP Datacasting . . . . . . . . 2.1.2 IPTV . . . . . . . . . . . . . 2.2 Triple Play . . . . . . . . . . . . . . 2.3 Business Models for mobile television 2.4 Summary . . . . . . . . . . . . . . .

3 Metadata framework 3.1 Electronic Program Guide . . . . . . . . . . . . . . . . . . . . . . . 3.2 Electronic Service Guide . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Open Mobile Alliance 4.1 Open Mobile Alliance OMA . . . . . . . . . . . . . . . . . . . . . 4.2 OMA BCAST Service Enabler . . . . . . . . . . . . . . . . . . . . 4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II

Investigation

23
25 25 26

5 User Interactivity 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 OMA Service Interaction Function . . . . . . . . . . . . . . . . . . xiii

xiv 5.2.1 InteractivityData fragment . . . . . . 5.2.2 Interactivity Media Document IMD 5.2.3 Interactivity Technologies . . . . . . . 5.2.4 Example of Interactive session . . . . Network aspects . . . . . . . . . . . . . . . . 5.3.1 Middleware . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 27 31 33 33 35 37

5.3 5.4

6 Investigation of the OMA BCAST Service Interaction Function 39 6.1 OMA BCAST Service Interaction Function issues . . . . . . . . . . 39 6.1.1 IMD issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.1.2 Interactive session issues . . . . . . . . . . . . . . . . . . . . 40 6.2 Preferred solution IMD . . . . . . . . . . . . . . . . . . . . . . . 41 6.2.1 OnActionPointer attribute . . . . . . . . . . . . . . . . . . . 41 6.2.2 Compressed alternative . . . . . . . . . . . . . . . . . . . . 42 6.2.3 Non-compressed alternative . . . . . . . . . . . . . . . . . . 43 6.2.4 Other Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.3 Preferred solution Interactivity session . . . . . . . . . . . . . . . 46 6.3.1 Proposed solution . . . . . . . . . . . . . . . . . . . . . . . 47 6.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

III

Implementation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51
53 53 53 54 54 55 55 56 56 56 57 57 60 62 62 62 62 63 63 63 63

7 System Architecture Description Demo application 7.1 Architecture overview . . . . . . . . . . . . . . . . . . . 7.2 General description . . . . . . . . . . . . . . . . . . . . . 7.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Client objectives . . . . . . . . . . . . . . . . . . 7.3.2 Server objectives . . . . . . . . . . . . . . . . . . 7.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Actors . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Use case description . . . . . . . . . . . . . . . . 7.6 System use cases . . . . . . . . . . . . . . . . . . . . . . 7.6.1 Distribute Interactivity Content . . . . . . . . . 7.6.2 Interact . . . . . . . . . . . . . . . . . . . . . . . 7.7 Third party products . . . . . . . . . . . . . . . . . . . . 7.7.1 Apache Commons . . . . . . . . . . . . . . . . . 7.7.2 Flying Saucer R6 . . . . . . . . . . . . . . . . . . 7.7.3 Flute implementation, MAD-FLUTE . . . . . . . 7.7.4 Java Architecture for XML Binding (JAXB) . . 7.7.5 Java Tar . . . . . . . . . . . . . . . . . . . . . . . 7.7.6 JDOM . . . . . . . . . . . . . . . . . . . . . . . . 7.7.7 Jetty . . . . . . . . . . . . . . . . . . . . . . . . .

7.7.8 Maven . . . . . . Content creation . . . . Logical view . . . . . . . 7.9.1 System overview 7.9.2 Server . . . . . . 7.9.3 Client . . . . . . 7.10 Summary . . . . . . . . 7.8 7.9

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

63 63 63 63 64 66 71

IV

Conclusions

73
75 77 79

8 Result and discussion 9 Future studies Bibliography

Appendices

83
85 85

A OMA BCAST Service Enabler A.1 OMA BCAST Service Enabler Service Guide Data Model . . . .

B File delivery protocol 89 B.1 File Delivery over Unidirectional Transport FLUTE . . . . . . . 89 B.1.1 RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . 89 B.1.2 RFC 3926 FLUTE - File Delivery over Unidirectional Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

xvi

Contents

Chapter 1

Introduction
This chapter gives background information and explaines the purpose of the thesis.

1.1

Background

Mobile television has been available on the market from time to time during the years, although it has never been a great success. Poor video quality and too expensive solutions have often been the contributory causes. The developement of digital formats during the latest years, have made it possible to achieve better video quality through better error correction and data compression. The recent developement has made it possible to stream video content to mobile phones using GPRS and 3G (UMTS) technologies. The third generation mobile technology (3G) was long been thought as the big breakthrough for mobile television but the congestion problems and high cost have lowered the expectations. Current mobile television solutions use unicast, a private channel between the end user and the service network is established which easily creates network congestion if many users within a radio cell wish to to watch streaming video at the same time. This has turned the focus to broadcast of digital data, datacasting, if the services are IP based, IP datacasting. IP datacasting technologies are used to deliver television and other IP based services in both terrestrial broadcasting and broadcasted mobile television. The regular television broadcasters who possess both the equipment and the experience of broadcasted television, have in many countries already initiated the change to digital broadcasting. In Sweden the terrestrial analog broadcasted television is currently closing down to be replaced with a digital technology called Digital Video Broadcasting Terrestrial [6]. Broadcasted television and service delivery is also of great interest in the mobile world. Three main technologies enable reception of digital television on handheld 1

Introduction

devices; ASTC1 [1], DVBH2 [5] and ISDB3 [24]. In Europe DVBH seems to be the technology of choice for broadcasted television to handheld devices. Another upcoming technology among the digital television enablers is Internet Protocol Television (IPTV). Television delivered to multiple users via broadband, a service not unlike the services delivered using radiowaves to televisions and handheld devices. The most obvious dierence is the natural access to a return channel in the broadband, something that is lacking in the terrestrial broadcast systems and limited in bandwith to the handheld devices (GPRS, UMTS etc.). Results from DVBH trials in Oxford [43] 2005, showed that the triallists viewed about 3 hours of television per week on their mobile phones and that news and sports were the most popular genres. Another thing that the triallist wanted was interactive services and live links to channel websites. With the ease of interaction on the Internet, users probably expect nothing less when watching television at home or on their mobile phone. An organization called the Open Mobile Alliance is currently leading the work on dening a global standard that enables broadcast of services to mobile devices, the sub working group responsible for this is called OMA BCAST. A service could be mobile television, VoD or software updates. The most central part of OMA BCAST is the Electronic Service Guide (ESG), a protocol or framework that describes what services that are available for the user and how to access them. Some of the information in the ESG is only meant for the terminal itself, like transmission information. Other information is intended to be presented to the user on screen, like an Electronic Program Guide (EPG), that describes the dierent TV-channels and their programs. The standard will also enable user interactivity related to a service, such as a poll or info ticker belonging to the current television program. OMA BCAST Service Interaction Function describes service interaction and is studied further in this thesis.

1.2

Purpose

The thesis was performed at Ericsson AB i Kista, Stockholm. It investigates the OMA BCAST Service Interaction Function and how to enable user interactivity according to this specication. This is done in two steps. 1. Theoretical investigation and evaluation of the OMA BCAST Service Interaction Function, discovery of aws and weaknessess. 2. Create a demo application that is using the OMA BCAST Service Interaction Function. The demo application will be used for presentation and evaluation of the Service Function specication. The OMA BCAST Standard species a couple of dierent types of interaction between a client and server. The type of interaction that lies within the scope of this thesis is called Service Interaction; interaction as a part of a
Television Systems Committee, http://www.atsc.org/ Video Broadcasting Handheld, http://www.dvb-h.org/ 3 Integrated Services Digital Broadcasting, http://www.dibeg.org/
2 Digital 1 Advanced

1.3 Problem description

service. A service could be a television channel and an example of service interaction could be a voting about the present TV-show, or a chat session with every post visible to everybody that watches the channel.

1.3

Problem description

At the beginning of the project the following requirements or objectives were identied for the thesis. 1. Discovery of weaknesses and problems of the OMA BCAST Service Interaction Function specication. 2. Implement the OMA BCAST Service Interaction Function. This will be implemented as a server and client. The client should be able to render the received interactivity content and let the user interact. 3. The server should use a transport agnostic mechanism for delivering interactivity content to the client. That is, a mechanism that is independent of the underlying network, i.e. the FLUTE protocol should be studied further. 4. OMA species two modes of delivering interactivity content. Compressed (gzip [16]) and non-compressed interactive content. Both modes should be discussed and implemented. 5. Create a nice looking graphical user interface for presentation of the interactivity session. In addition to the objectives given above, requirements where dened for the demo application, dened in Chapter 7.3.

1.4

Method

A demo application has been implemented in Java to investigate the feasability of delivery and presentation of interactive content using specications from OMA BCAST. The following workow is expected. 1. Literature study of OMA BCAST, Mobile-TV/IPTV and IP datacast solutions. 2. Investigation of OMA BCAST Service Interaction Function. 3. System design of demo application. 4. Implementation 5. Documentation.

Introduction

1.5

Limitations

Some restrictions have been set due to the obvious fact that the project is limited in time. Due to this the application will be developed to run on a PC client and not an actual mobile phone. It will only use XHTML as interactivity technology. To enable a broadcast mechanism to deliver interactivity content from server to client the FLUTE protocol should be used. A third party program called MAD FLUTE will be used. Implementation of a FLUTE delivery application is not within the scope of this thesis, therefore the application will dependend on the capabilities of the MAD FLUTE program.

1.6

Outline

The thesis is divided into ve main parts, Theoretical Background, Investigation, Implementation, Conclusions and Appendencies. The scope of each part is explained below. Part I: Theoretical Background This rst part of the thesis serves as an introduction to the world of digital television and IP-based services. The information will be used as knowledge base for discussions in later parts. Chapter 2 IP Datacasting This chapter describes the fundamentals of IP Datacasting, Triple Play and dierent business models of Mobile Television. Chapter 3 Metadata framework This chapter introduces the electronic program guide and the electronic service guide, which are frameworks for carrying metadata of the oered services. Chapter 4 Open Mobile Alliance This chapter presents the organisation Open Mobile Alliance and its sub working group called OMA BCAST. OMA BCAST is an enabler of broadcast services, from which specications are used in this thesis. Part II: Investigation Chapter 5 User Interactivity This chapter gives an introduction to user interactivity related to a service. It also presents the OMA Service Interaction Function which is the specication that enables interactivity in OMA BCAST. Chapter 6 Investigation

1.6 Outline

This chapter discusses dierent problems and weaknessess with the OMA Service Interaction Function. A number of solutions to the different issues are also presented. Part III Implementation Chapter 7 System Architecture Description Demo Application This is a System Architecure Description of the implemented demo application. It provides use cases, architecture and describes both the server and client. Part IV: Conclusions Chapter 8 Result and discussion This chapter provides a summary of the thesis results. Chapter 9 Future studies Some possible future studies are discussed. Part V: Appendencies Appendix A OMA BCAST Service Enabler This appendix gives an introduction to the OMA BCAST Service Guide Data Model, the electronic service guide declared by OMA. Appendix B File delivery protocol This appendix explains and describes a le delivery protocol called: File Delivery over Unidirectional Transport FLUTE. An experimental protocol for broadcasting les over any IP-network.

Introduction

Part I

Theoretical Background

Chapter 2

IP Datacasting
This chapter introduces dierent standards for broadcasting digital services and a discussion about business models.

2.1

Digital Television

The term datacasting refers to broadcasting of digital content via radio waves. IP Datacasting is also referring to broadcasting of digital content, but it includes delivery of Internet Protocol based services [25]. Many of the digital broadcast formats today enbles delivery of IP based services. Since a television set not is able to decode the digital content, which can be of many formats, a set top box (STB) is used to receive the content. The STB translats the streams to something that a television is able to render.

2.1.1

IP Datacasting

IP Datacasting is often realized using a unidirectional broadcast path that is combined with a bi-directional interactivity path. IP Datacasting thus enables reception of content and services to many people simultaneously and at the same time it allows for a return channel. It is a UDP/IP service, with no guarantee of data delivery. Instead forward error correctional coding is used and the content is delivered many times to guarantee complete receival. Digital Terrestrial Television Broadcast DTTB In Europe and many other places operators are currently testing and releasing applications supporting a format called Digital Video Broadcast Terrestrial (DVB T). In Sweden the public terrestrial analogue television net is in the process of closing down and is being replaced by DVBT transmissions. DVBT is using Coded Orthogonal Frequency-Division Multiplexing (COFDM) with QPSK, 16QAM or 64QAM modulation. Source coding methods for video and audio are MPEG-2 and H.264. [6] 9

10

IP Datacasting

Two of the other DTTB standardization bodies are the ATSC and ISDB. The Advanced Television Systems Committee (ATSC) has developed the digital television standard used in the United States, Canada and a number of other countries in Central and South America. ATSC is using 8-VSB and 256QAM as modulation scheme. The standard uses 6MHz bandwith and can deliver one HDTV channel of 1920*1080 pixels resolution or six regular SDTV channels. As transport stream the MPEG-2 specication is used and Dolby Digital AC-3 is used for audio coding. [1] Integrated Services Digital Broadcasting (ISDB) is the format for broadcasting video and audio developed and used in Japan. ISDB is using Orthogonal Frequency-Division Multiplexing (OFDM) with QPSK, 16QAM, 64QAM or DQPSK modulation. Source coding methods for video and audio are MPEG-2, H.264 and Advanced Audio Coding (AAC). [24] Many of the digital television formats mentioned have their own specication for end user interactivity. For DVBT, one specication is called DVBReturn Channel Terrestrial (DVBRCT). The DVBRCT is a specication of the physical layer of the return channel from set-top box (STB) to broadcaster, it enables a large number of subscribers to interact with a bit rate of several kbits per second using the UHF/VHF bands [14]. ATSC has also dened specications for interaction, but in this case the physical layer and the data link layer are not dened. The specication instead denes interactivity sessions using TCP/IP or UDP/IP in the network layer and the transport layer of the protocol stack [2]. All of these three standards enables IP datacasting. User interactivity using specications from the Open Mobile Alliance is discussed in greater detail in Chapter 5.2. Mobile Broadcast Services Data broadcast intended for mobile devices is probably the next mobile feature that draws the most attention today and mobile television is the one part with the highest focus. But mobile broadcasting enables more than broadcast of video content. Software updates and game delivery are other services of interest. A number of techniques for digital broadcasted television intended for mobile or handheld devices are presented below. Digital Video Broadcast Digital Video Broadcast Handheld (DVBH) [5], was developed from DVBT to support handheld receivers, such as mobile phones. The biggest dierence between the two is that a system for handheld devices will have to deal with low power terminals, cell-to-cell handover and mobile multipath reception. To solve these problmes DVBH uses time slicing and optional Forward Error Correction (FEC) coding scheme. Time slicing reduces the average power consumption of the terminal, this since data is sent in high data rate burst and the terminal can go into idle state between the bursts. It also enables a smooth cell service

2.1 Digital Television

11

handover, since the terminal can monitor neighbouring cells between the bursts. The FEC objective is to improve the channel to noise ratio and enhance the Doppler performance in mobile channels and also to improve the tolerance to impulse interference [13]. Integrated Services Digital Broadcasting - One segment service ISDB is using a segmented OFDM, 6MHz of bandwidth is divided into 13 segments of which 12 are used for one HDTV channel or 3 SDTV channels for stationary receivers. The 13th segment is carrying LDTV, audio and data and is intended for mobile reception, thus no extra frequency spectrum is needed to deliver mobile television. This is called One-Seg and allows data rates of up to 256kbit/s for video content, 64kbit/s for audio and 80kbit/s for data broadcasting. The data broadcast intendend for on screen presentation is using Broadcast Markup Language (BML). Apart from these, there are several other delivery modes that enable TV reception on smaller devices. MBMS (Multimedia Broadcast/Multicast Service) Developed by the 3GPP (Third Generation Parnership Project) and is a solution that uses the existing GSM EDGE Radio Access Network (GERAN) and UMTS Terrestrial Radio Access Network (UTRAN) to transfer (broadcast and multicast) light video and audio clips like news clips and audio streams [31]. MediaFLO MediaFLO technology is a proprietary format developed by QUALCOMM and is used on the North American market. It is an end-to-end solution that enables video/audio multicasting, IP datacasting and Interacitive services etc. [42]. WorldDMB (World Digital Multimedia Broadcasting) The WorldDMB, the forum that also developed Digital Audio Broadcasting (DAB), has developed two new standards that enables mobile television. Digital Mobile Broadcasting (DMB) which is based on DAB and DAB-IP which enables IP Datacasting to mobile users. DMB is currently used for mobile television in South Korea, test runs of DAB-IP have also been executed in the UK [3].

2.1.2

IPTV

The broadband based Internet Protocol Television, or IPTV, represents a new generation of digital television. IPTV can be a confusing notion since all of the previously discussed service providing systems are also based on the internet protocol, another word could also be Broadband Television BTV. Television delivered

12

IP Datacasting

over broadband. IPTV can be seen both as a complement and as a competitor to the existing satellite, cable and terrestrial systems since it can be used to deliver the same services. By the telecom industry, IPTV is promoted as a new broadband digital technology [7], a technology that oers voice, data and video. A real denition of IPTV does not exist but the general idea is that it refers to IP-based distribution of television and video content to end users via broadband and that it should be presented on a TV-set. The IP-addresses of the subscribers are known, they are also authenticated and the media itself is protected. IPTV should oer an end to end Quality of Service (QoS), dierent users or data ows have dierent priority and a certain level of performance to a specic data ow should be guaranteed [22]. It should not be mistaken for Internet Video Streaming which is meant for personal computers via the Internet without quality guarantee. IPTV requires a set-top box for rendering the video content. The ITU-T1 is currently working on the standardization of IPTV. All commercial systems today are proprietary and interoperability of user equipment and software is lacking. A modem or set-top box from one operator can not be used by someone subscribing to services from another operator. The IPTV market is still small, but there are some success stories of IPTV services in both France and Italy [7] oering both VoD and broadcasted television via broadband.

2.2

Triple Play

Until recent years telephony, television and the internet have been three separate markets, but with the success of the Internet and with faster connections, this is about to change. The telecommunication companies are extending their scope of activities to include triple play: television, telephone and internet over the same broadband connection. Triple play aims to provide a whole new set of services to the users [8], among these: Broadcast Television Scheduled broadcasted television. Interactive Services Program guide, targeted advertising, intereactive gaming etc. Interactive Television Time shifted television or the ability able to change camera angle etc. Video on Demand Demand movies or clips from a selection. This new market has created a whole new set of business models, some of them are discussed in Chapter 2.3.
1 International

Telecommunication Union, http://www.itu.int/ Focus Group on IPTV

2.3 Business Models for mobile television

13

Figure 2.1. Highlevel model of the system

2.3

Business Models for mobile television

Mobile-TV is the convergence between broadcast and mobile telecommunications. [30]

UMTS (3G) was initially meant to provide and deliver media content to the end users, but congestion problems in the networks and new technologies such as DVBH are now allowing broadcast delivery of media content with a reduced delivery cost and delivery to a large audience. The terrestrial broadcast companies already possess the knowledge and infrastructure of broadcast transmissions and the telecommunication companies have got the knowledge and equipment for the interactivity channel (SMS, UMTS, ets.). The telecommunication companies are also experienced in service/subscription charging. To be able to oer a full scale solution of broadcasted television togheter with a return channel for interactivity to the customers, some kind of collaboration is probably needed between the broadcaster and the provider of a return channel, i.e. the cellular network operator. On the other hand the telecommunication operators have got a large number of subscribers and great marketing skills [4]. A highlevel model of the system is depicted in Figure 2.1. One important aspect to take into consideration, is that the service provider and the provider of interactivity does not necessarily need to be the same entity. A service provider could provide the broadcaster with a TV-Channel and another company could deliver the interactive content or personalized advertisement belonging to the current TV-show. Many dierent companies could also be interested in providing advertisement and such, which opens up for a need of an aggregator mechanism. A separation of the actual content and transport information and parameters is probably needed. Content of any kind, advertisement, interactivity etc., that can be developed by external sources, should not contain information that the content provider has no knowledge about.

14 Broadcaster led approach

IP Datacasting

Mobile television could be a service oered by the terrestrial broadcasters that are already experienced with content aggregation and have a large existing audience. Figure 2.2 depicts a value chain for this solution. The broadcasting company delivers television content and the interaction channel is provided by the cellular network operator. The broadcasters will manage the relationship with the end user regarding the broadcast services. The users may be forced to pay both the cellular network operator for the use of interaction channel and the broadcast companies.

Figure 2.2. Value Chain example 1: Broadcast operator managed system

Mobile telecom operator led approach In an end user perspective, the most intuitive way of adding a video reception feature to the mobile phone is probably to call the operator and not the local terrestrial broadcaster, to take out a subscription. With the introduction of new services such as VoD & Pay-per-View, betting and voting a whole new set of actors enter the market. New business scenarios and opportunities for the telecommunication companies, mobile companies and the media industry and the content industry are created. A number of dierent content providers and advertisers will be able to expose their services to the customers. Some kind of aggregating mechanism is therefore needed to be able to receive content from dierent sources and then make it deliverable over a broadcast network. Other instances in the value chain of the mobile television are generation of ESG, content protection and the actual content delivery. A mobile operator led system is depicted in Figure 2.3. The aggregation of content could also be managed by the mobile telecom operator. In this case the broadcast network operators only provide the distribution mechanism for DVB-H or any other suitable bearer. The users are provided with a service oered by one single provider, the existing mobile telecom operator.

2.4 Summary

15

Figure 2.3. Value Chain example 2: Mobile telecom operator led system

Besides from this the cellular network operators will be able to deliver audio/video content via MBMS, described in Chapter 2.1.1, using the existing cellular network.

2.4

Summary

This chapter has introduced digital television and IP Datacasting. At rst, the three largest digital terrestrial television broadcast standardization organizations and their standards were introduced. Then broadcasted mobile television and broadcasted mobile services was discussed. IPTV over broadband is an upcoming television and service enabler which also is briey introduced. Some dierent business models of mobile television were also discussed.

16

IP Datacasting

Chapter 3

Metadata framework
This chapter introduces the electronic program guide and the electronic service guide, which can be seen as frameworks for carrying metadata to the oered services.

3.1

Electronic Program Guide

The Electronic Program Guide, or EPG, is an on-screen TV-guide with schedule and description of the TV-Channels. The EPG allows the user to navigate through the content of TV-channels and also search or select the content in many dierent ways, using a remote control or the keypad of a mobile phone. The EPG can contain information about TV-shows, movies, actors etc. The concept of the EPG has been used on the internet and for digital television for some time now, most often as a replacement to the ordinary TV-Guide in the paper. Most of the EPG standards are proprietary, many digital-TV providers have their own EPG version. TV-Anytime [12] is a fully developed protocol for the EPG that is open to the public.

3.2

Electronic Service Guide

To be able to describe other services than ordinary television that can be enabled using IP Datacast, more information besides the EPG is needed. Therefore the Electronic Service Guide, ESG, was introduced. A way of specifying transmission parameters, information about provisioning etc. The ESG enables the Content Providers to describe the services and content that they make available to the end users. It also contains information on how to access the services and their content. Some data in the ESG is for on-screen information to the user, like the information in the EPG, and some data is only for the terminal such as transmission/access information, parameters etc. An example of a service could be a TV-channel; the ESG can then be used in traditional digital television, IPTV and mobile television, to let the end user know what channels 17

18

Metadata framework

that are available to watch and how to access them. Another example could be a Video on Demand (VoD) service, the user is then able to choose and download dierent video clips from a selection. There are a lot of protocols and standards for the EPG, most of them proprietary, being developed today. A sub working group of the OMA called BCAST is currently working on a denition of a mobile broadcast service enabler called OMA BCAST Service Enabler, which also contains a specication of the ESG also is included. The OMA BCAST Service Enabler is discussed in Chapter 4.2.

3.3

Summary

A lot of information is needed to broadcast services of any kind. In mobile television the framework of how to deliver and arrange service information or metadata, is often called Electronic Service Guide.

Chapter 4

Open Mobile Alliance

This chapter introduces the Open Mobile Alliance and presents their service enabler for mobile handheld devices, OMA BCAST Service Enabler.

4.1

Open Mobile Alliance OMA

The mission of the Open Mobile Alliance is to facilitate global user adoption of mobile data services by specifying market driven mobile service enablers that ensure service interoperability across devices, geographies, service providers, operators, and networks, while allowing businesses to compete through innovation and dierentiation. [38]

The quote above explains the scope and mission of the Open Mobile Alliance. The organization was formed in 2002 by almost 200 companies. During the years other organizations have also been integrated with OMA, WAP Forum [47] and Location Interoperability Forum [27] are two of them. WAP Forum was focused on browsing and provisioning protocols and the Location Interoperability Forum was developing a structured way of oering location based services world wide. The OMA is not a government-sponsored organization for standardization, instead it works as a forum for the industry to agree on common specications for data services. Existence of network technologies specied by outside parties is presumed and the specications that are developed are transport agnostic, the specication is the same regardless of the underlying network. BCAST is a sub-working group within the OMA that was created to dene the requirements for an enabler of Mobile Broadcast Services and specify the needed functions. These functions are packed together and delivered as a Service Enabler which is network agnostic, any broadcast bearer is applicable (DVB-H, 3GPP MBMS etc.). The Service Enabler consist of several functions, these include; Service Guide, Content Protection, Service Protection, Interaction, Purchase and Payment, File delivery and Service provisioning [46]. 19

20

Open Mobile Alliance

4.2

OMA BCAST Service Enabler

The OMA BCAST Service Enabler is a bearer agnostic application layer for broadcasted services. These services could for instance be mobile television, interactive games or software updates. The bearer aspects of mobile television and other services are already well dened with technologies like DVBH, over regular IP broadcast networks, and 3GPPMBMS for cellular networks. The receiving terminals are all dierent kinds of terminals, although handheld clients are the main target [35]. The OMA BCAST Service Enabler consist of several functions such as Service Guide, Content Protection, Service Protection, Interaction, Purchase and Payment, File delivery and Service provisioning. The idea is to distribute content using two channels: a broadcast channel and an interactive channel. The broadcast channel will enable transmission of streaming video, television, video on demand etc., but also delivery of the ESG and other suitable services such as software updates. The broadcast channel should be realized using an IP based broadcast network, like DVB-H or MBMS. The transport stream is a MPEG-2 transport stream and on top of that there is UDP/IP. Audio and video streaming will probably be delivered using some streaming session protocol like RTP or RTSP will be used. When delivering les over the IP broadcast channel, a protocol called File Delivery over Unidirectional Transport FLUTE is assumed to be used. This protocol is using any IP multicast/broadcast network as underlying network service and is explained in greater detail in Appendix B.1.2. The interactive channel is realized with GPRS, SMS etc. and can be used for user feedback and personalized content requests, Figure 4.1.

Figure 4.1. Broadcast channel & interaction channel

4.2 OMA BCAST Service Enabler

21

Figure 4.2. OMA BCAST Service Guide Data Model [39].

22 OMA BCAST Service Guide Data Model

Open Mobile Alliance

The Electronic Service Guide is one of the most central parts of the OMA BCAST Service Enabler since it is the actual framework in which all the information about the available services reside. Figure 4.2 depicts the Data Model of the OMA BCAST ESG. The boxes in the gure are referred to as fragments of the Service Guide, the fragments contains meta-data and information about the service represented as XML. The ESG can consist of many services, all of which have this structure of meta-data. A typical structure of the ESG could be to have a Service fragment representing a broadcasted TV-channel, then there would be Schedule fragments and Content fragments for each TV-show. If there are multiple languages available for the TV-show then there would have to be multiple Access fragments related to each programme to describe how to watch the show with the preerd language. PreviewData could contain a logo of the TV-channel or a small advertisement clip. A detailed description of the ESG Data model is given in Appendix A.1. The most interesting part of the ESG from the scope of this thesis, is the InteractivityData fragment. This fragment contains information about interactive sessions, declares availability of interactive components, and is used to associate a service with that session. The actual interactivity session is described in detail in another le or document called Interactivity Media Document, IMD and the IMD is referenced from the InteractivityData fragment. The IMD is received over any IP broadcast network using the FLUTE protocol. A terminal needs a return channel to be able to support the InteractivityMedia fragment, see Chapter 5.2.

4.3

Summary

This chapter introduced the Open Mobile Alliance and some of its related work. The BCAST Service Enabler was especially focused. The terminology of broadcast channel and interactive channel are mentioned and explained. The data model of the ESG was presented and user interactivity was introduced.

Part II

Investigation

23

Chapter 5

User Interactivity
This chapter explains the fundamentals of user interactivity in mobile television, IPTV and also regular digital television.

5.1

Overview

User interactivity can be dened in a number of ways. Most often it is about interactive services, such as the electronic program guide, interactive gaming or perhaps personalized advertisements. Another type of interactivity could be interactive television, TV-shows could be ordered on demand or a selection of dierent camera angles could be available. Many times the end user should be able to react to the ongoing service, interactivity related to a service. This is meant to enhance the end user experience by allowing him/her to participate in a vote session, receive personalized advertisement related to the current TVshow or maybe buy something related to the show. Another example could be a chat session, a user writes a comment which will be presented as a text scroll to all users watching that particular channel. Interactivity has already existed for some time in regular digital cable television, but the data rate of the return channel is not higher than a few kilobits per seconds and often proprietary format. Many of the current solutions for interactivity in DVBT or DVB for satellite transmission, DVBS, are using a broadband return channel, the set-top box is running some kind of middleware application that is connected to the Internet. The application running could be a implementation of the open standard Multimedia Home Platform (DVB-MHP) [32] or of some other proprietary format. The basics of middleware applications are discussed in Chapter 5.3.1. There has also been some testing of DVBRCT, but still are no real business implementations available [41]. Interactivity data that is delivered along with the audio/video data in a cable television network can be referred to as in-band interactivity [11]. This approach has several limitations. Since it is heavy on processing power on the end user side, it requires an advanced set-top box. It is also based on a narrow feedback channel 25

26

User Interactivity

which limits the user experience and the interactivity provisioning is limited to the TV program providers. IPTV provides a far more exible model for end user interactivity, its main advantage is the separation of the interactivity content and actual audio/video feed. This is enabled by the two-way communication channel, it is therefore ideally referred to as out-of-band interactivity. This will reduce the complexity of the end user client, it allows for a thin client with a simple implementation, and also additional business scenarios. By broadcasting all content that belongs to a interactivity session to many users at the same time, the risk of network congestion is reduced: Instead of letting every user request content, pictures, webpages etc., related to the interactivity session separately when they are needed, all objects are allready received via broadcast transmissions and cached in the memory of the device.

5.2

OMA Service Interaction Function

The OMA BCAST Service Enabler species four dierent types of interaction between end user terminal and the service provider. Two of them are concerning the retrieval of the actual ESG over the interaction channel. The third type is the retrieval of information related to the ESG, this could be a webpage that presents supplementary information. The fourth and last type is the interaction as a part of a service, this could be a poll about the current service or an advertisement related to the service. Service Interaction is specied in the specication OMA Broadcast Services Technical Specication [37], which is a part of the OMA Service Enabler. Service Interaction is used to deliver and process trigger messages intended for the end user terminal or for presentation to the end user on the terminal. These trigger messages are realized as a Interactivity Media Document (IMD). The IMD describes the interactivity session and the objects needed to enable the interactive session. A media object is the actual data object that should be part of the interactive session and presented to the end user, the data objects could be pictures, webpages, stylesheets etc. In this paper the IMD and the actual media objects will be refered to as interactivity content. By broadcasting the interactive content and letting the terminals cache all content that belongs to a certain interactivity session, the system load and the required bandwidth are reduced. Many simultaneous requests of interactive content from the terminals could otherwise put a to high load on the networks. If the terminal caches the interactive content, a browser could be enough to render the session. A proxy could then be used to simply redirect the requests from the browser to the cache. The OMA Service Interaction Function enables many dierent interactivity technologies to be delivered to the end user. The IMD contains templates for both email and sms voting. No presentation information is then provided and the client should be able to render the template. Besides the templates interactivity sessions using technologies like XHTML or SVG can be used. The demo applica-

5.2 OMA Service Interaction Function

27

tion developed is using XHTML for presenting interactive content to the user, see Chapter 7. The general idea is that the interactive content, the IMD and its declared media objects, are delivered over a IP multicast network such as DVBH or MBMS, using the FLUTE protocol. The interactive content is distributed over the same access channel as the service it is associated with. The information needed to set up the FLUTE reception to receive the interactive content is therefore assumed to already exist. Since the study of FLUTE is part of the problem description, point 3 in Chapter 1.3, an introduction to FLUTE is given in Appendix B.1.2. InteractivityMediaDocuments can be distributed over the same access channel as the service they are associated with, or over a dierent access channel. Distribution over a dierent access channel is enabled by association of an InteractivityData fragment to a Schedule fragment that is referred to by a dierent Access fragment than the service. The user response is returned to the server system on a return channel such as GPRS, SMS etc.

5.2.1

InteractivityData fragment

The InteractivityData fragment of the Service Guide Data Model, Figure 4.2, is used to associate broadcast services with Interactivity Content. These components are used by the terminal to oer interactive services to the end user along with the broadcast content. The InteractivityData fragment declares the availability of an interactivity session and refers to the IMD(s) which in turn contains details about the interactivity content. Terminals require a return channel, SMS,TCP/IP etc., to support InteractivityData fragments.

5.2.2

Interactivity Media Document IMD

The IMD is an XMLdocument that describes the media objects that are related to a specic service. The complete XML-schema of the IMD can be found on the OMA webpage [36]. As described in Chapter 4.2 the IMD is referenced from the InteractivityData fragment in the ESG, see Figure 5.1. The main structure of the IMD can be found in Figure 5.2, the attributes are not shown. The structure of the IMD makes it possible for the terminal to control the interactivity session. IMDs can be distributed over the same access channel as the service they are associated with, or over a dierent access channel. If a dierent access channel is used, this channel is accessed with the use of information in another Access fragment. The described content should also be retrivable over the interaction channel using the InteractivityMediaURL dened in the InteractivityData fragment. The root element of the IMD, InteractivityMediaDocument, is of cardinality 0..N and contains six dierent attributes, groupID, groupPosition, id, version, validFrom and validTo. The groupID is an ID of the group of IMDs, probably belonging to the same interactivity session - not quite clear, the groupPosition is

28

User Interactivity

specifying a relative position of the IMD in the group of IMDs. The id is globally unique and identies the IMD, newer versions of IMDs overrides the old ones when they are received. validFrom and validTo species when the IMD is valid. This InteractivityMedia XML-document has sub-elements called MediaObjectGroups. The most important sub-elements to the MediaObjectGroup are the MediaObjectSet, Figure 5.3, BackoTimer, Figure 5.5 and the ActionDescriptor, Figure 5.4. In a real business scenario the IMD will probably be created by the network operator. The content provider delivers the media objects and a vision of how the actual session should be presented, to the operator. The operator then generates the IMD with the correct parameters and transmission information. Besides this, the InteractivityData fragment of the ESG is also created by the operator along with the rest of the ESG. Element: MediaObjectGroup A MediaObjectGroup is a way of sorting the media objects depending on what purpose they serve and when they should be used in an interactivity session. A MediaObjectGroup could contain information about media objects that should be rendered at the beginning of the interactivity session, another MediaObjectGroup could consist of objects to show when action has been taken by the user. The MediaObjectGroup also contains templates for email voting and SMS voting. Element: MediaObjectSet A MediaObjectSet declares a bundle of related media objects that are meant to be rendered as a unit (ex. XHTML-pages + external stylesheet + pictures). One MediaObjectGroup could contain many MediaObjectSets, one for each interactivity technology - XHTML, SMS etc. The declaration points out an external le, a compressed archive le of gzip [16] type, which can contain several media objects like XHTML + picture. Alternatively, it declares one single uncompressed media le. The actual data le, or media object, is then retrieved over FLUTE or requested using the interactive channel. The terminal renders the MediaObjectSet with the highest relative priority that is also supported. This structure allows the terminal to parse the IMD and check which MediaObjectSets that are supported and then only receive and cache these over FLUTE or maybe pull them from the server. Element: ActionDescriptor The ActionDescriptor, Figure 5.4, describes the behaviour of the terminal depending on the end user action. If the end user does not react before the time given in the attribute inputAllowedTime, the pointer of attribute onTimeOutPointer redirects the terminal to next MediaObjectGroup, which is rendered

5.2 OMA Service Interaction Function

29

Figure 5.1. Relationship between InteractivityData fragment and the IMD

30

User Interactivity

Figure 5.2. Interactivity Media Document Schema.

5.2 OMA Service Interaction Function

31

on the terminal. When the user undertakes action within the given time interval the onActionPointer explains which new MediaObjectGroup to show. By omitting the onActionPointer, XHTML hyperlinks can refer the user to external webpages. Otherwise the only references made between MediaObjectGroups are with the use of onActionPointer(s). The last attribute of the ActionDescriptor is the updateFlag. When this is set to true the terminal should start to listen for a new IMD on the broadcast channel when the inputAllowedTime is passed. Element: BackoTimer A time window is specied to avoid network congestion if too many terminals send feedback at the same time to the service provider. The element has got two attributes; randomTime and osetTime. The time window is [osetTime, osetTime + randomTime], and the exact time of feedback transmission should be random with uniform probability within this intervall.

Figure 5.3. Element: MediaObjectSet

5.2.3

Interactivity Technologies

The specication Mobile Broadcast Services [37] presents a set of rules regarding the support of protocols in the terminals. The terminal shall support the following protocols: IP, TCP, HTTP.

32

User Interactivity

Figure 5.4. Element: ActionDescriptor

Figure 5.5. Element: BackoTimer

5.3 Network aspects

33

The terminal may support the following protocols: SMS, IPsec 1 , UDP, MMS, WAP, HTTPS, SIP/IMS. If a terminal supports SMS, it SHALL support SMS as an interaction protocol for BCAST services. If a terminal supports MMS, it SHALL support MMS as an interaction protocol for BCAST services. If non of these protocols are supported the interactive parts shall not be oered to the user. The specication also suggests how to arrange the MediaObjectSets depending on the technology used. If a MediaObjectSet of a MediaObjectGroup is describing a MMS Message Template for interactivity it shall consist of a gzip archive le containing the MMS presentation part and all the dierent media objects. Each bundled le should be declared in a Object element of the MediaObjectSet. If the user chooses to participate in the session, the MMS template is then lled in and sent back via the interaction channel, realized as MMS. The instructions when using XHTML are similar. One gzip archive le containing all the media objects that should be rendered at a specic point in the session is declared in a MediaObjectSet. Every object in the archive le is then declared as a Object element. If this type of interaction is triggered, the terminal shall be able to execute HTTP-request over the interaction channel.

5.2.4

Example of Interactive session

In Mobile Broadcast Services [37] there is an example of how an interactivity session could be dened. Figure 5.6 depicts this session. A time-dependent behaviour of the session can be enabled by dening 3 MediaObjectGroups in the IMD. The rst declares which media object to start with, like a list of possible answers to a poll. If the user then answers in time, he/she is presented with the MediaObjectSet from the MediaObjectGroup dened by the OnActionPointer. If the user waits too long or does not provide any input the MediaObjectSet from the MediaObjectGroup dened by the OnTimeOutPointer is presented. If the UpdateFlag is set to true, the terminal should listen to the delivery channel for a new IMD. This new IMD could then dene the next question in the voting session.

5.3

Network aspects

Three new, or modied, digital broadcasting technologies have been discussed so far, IPTV and IP Datacasting (mobile television and DTTB). There are attempts in the industry to converge these technologies, or at least provide the same set of
1 IP

Security mostly described in rfc2401, www.ietf.org/rfc/rfc2401

34

User Interactivity

Figure 5.6. Interactive session according to the OMA

services on all three of them. The same TV-channel or service should be accessible on both a mobile phone as well as on the regular television set. Frank Kozamernik identies three dierent areas of synergy beween IP datacasting and IPTV in IPTV a dierent television [7]: Complementary coverage Digital terrestrial broadcasting is often designed to cover huge territories. The requried cost to create this kind of nation wide network infrastructure to enable IPTV for everyone is probably to high today. Instead IPTV could work as a complement where the coverage of terrestrial broadcast is insucient. Common sets of services The same services should be available over both broadband and broadcast, this would also enable the complementary coverage mechanism. Common set-top boxes A common set-top box for reception of both IP datacasting and IPTV is neccessary to enable the two previous points. Chapter 5.3.1 presents middleware applications of set top boxes, especially the Multimedia Home Platform (MHP), and discusses the possibility of delivering MHP data using the OMA framework. A mobile phone is not capable of handling the same amount of data as a settop box or a home multimedia system and the OMA specications are intended

5.3 Network aspects

35

for mobile phones and other handheld devices. The use of OMA specications is probably not enough for the stationary home systems were the user expects a richer experience. Nothing in the OMA BCAST Service Enabler says that the interactive function not can be used in IPTV, eventhough it is intended for handheld devices. The end user experience in terms of interactivity can probably be richer if some other solution than the OMA BCAST Service Interaction Function is used. To deliver IPTV to households, much of the information of the ESG is not needed. Cell information or network parameters are not needed since the signal is transmitted in dedicated cables. This makes some of the information of the ESG redundant if it should be used to deliver information to an IPTV set-top box. One application platform, or middleware, that has been tested widely on set top boxes to provide interactive television is the Multimedia Home Platform (MHP). It is a huge standardized framework for delivering and presenting interactive television for digital television. In some aspects MHP could be considered to be the equivalent to the OMA BCAST Service Enabler but in the digital television world, therefore some space will be given introduce MHP in this thesis.

5.3.1

Middleware

http://www.iptvnews.net denes middleware as a Layer of software that provides a common interface and translation between an application and an operating system or other system services.. The middleware can often be referd to as an Application Programming Interface (API) used to let the user access interactive applications and services regardless of which platform they run on. Regular digital television (terrestrial, cable or satellite) uses some kind of middleware in the set top boxes to present interactive content and applications to the user. There exists an abundance of dierent standards for middleware applications that are used on set-top boxes for digital television. Proprietary solutions have been available for several years, but now the thoughts of open standards have reached even the middleware market. The proprietary solutions were developed in the early life of digital television when operators wanted to enable interactivity applications on the set top boxes. When the interactive television got a bigger audience, open standards were requested for the middleware running on the set top boxes. The open standards are developed by the same organizations that have created the digital television standards. DVB in Europe, ATSC in the United States and the Digital Broadcasting Experts Group (DiBEG) in Japan. The DVB is behind a project called Multimedia Home Platform (MHP), the Advanced Common Application Platform (ACAP) is developed by the ATSC and DiBEG has created the Broadcast Markup Language (BML). This chapter will focus on the MHP, since it is intended for DVB transmission which is used widely in Europe, currently for terrestrial transmissions and satellite transmission but maybe soon also for mobile television.

36 Multimedia Home Platform MHP

User Interactivity

The MHP is huge, with many dierent proles and complex relationships with other standards. Therefore it is not possible to give a complete introduction to MHP in this thesis. It is enough to know that there are four main parts of the MHP [40]: DVB-J Platform: Support of Java applications, consist of a Java Virtual Machine (JVM) and a set of television specic application programming interfaces (APIs). Content formats: images, video subtitles and downloadable fonts. DVB-HTML: Support for web browsing. Network: Denes broadcast access and interaction channel usage. So there are two ways of implementing broadcast applications, with the use of Java, DVB-J or with XHTML using DVB-HTML. The applications that should be designed to run on a MHP device must use only the specied subset of Java and XHTML dened in DVB-J and DVB-HTML. DVB-J is intended for interactive applications, DVB-HTML is meant for information services but is currently not used [33]. An application intended for MHP, as well as an application to be run on a mobile phone, is not expected to crash. DVB-J contains four main packages that run on the JVM [40]: Sun Java APIs Core Java: Basic APIs for Java applications. JavaTV: The lifecycle of a Java service application in MHP is dened in the JavaTV [44]. Java Media Framework (JMF): Enables control of broadcasted video and audio. Home Audio/Video interoperability(HAVi) Level 2 UI: Extends the Java components in television presentational purpose, i.e. integrate graphics with video. Digital Audio Video Council (DAVIC): Tuning between MPEG streams and basic MPEG functionality. DVB: Handles access to service information and such. There are three dened proles of MHP to create a smooth transit from the analogue television: Enhanced Broadcast A prole for low cost receivers for accessing broadcasted services and should provide the same functionality as the existing middleware systems.

5.4 Summary

37

Interactive Broadcast Same as the Enhanced Broadcast prole with the addition of return channel support. Internet Access Broader support for Internet applications such as web browsing and email. It also includes a Java APIs and a Java Virtual Machine. So the OMA is providing means of interaction with the use of any W3C 2 technology, like XHTML or SVG, the MHP has dened a set of technologies to use for interactive television. The main dierence between the two is the delivery of Java applications from server to client in MHP, something that does not exist in the OMA BCAST. Other dierences are the amount of transmission metadata and parameters. Since MHP is intended for xed radio networks it does not need information regarding cellular handover and such, as in the OMA BCAST.

5.4

Summary

A general introduction to user interactivity was given. The OMA BCAST Service Interaction Function was explained which is the part of OMA BCAST Service Enabler that describes how to enable interactivity as a part of a service. The InteractiveMediaDocument was described in detail, as well as an example of how the OMA would like to present interactivity if the chosen technology was XHTML. Some thoughts on what would be required to converge the dierent broadcast technologies are mentioned along with a short introduction to the application layer that is currently being developed for ordinary digital television to enable interactivity, the Multimedia Home Platform.

2 World

Wide Web Consortium, http://www.w3.org/

38

User Interactivity

Chapter 6

Investigation of the OMA BCAST Service Interaction Function

This chapter discusses the dierent problems and issues that have arised during the work with the OMA BCAST Service Interaction Function, thus it fulls point 1 of Chapter 1.3. This chapter also gives dierent solutions on how to realize two dierent delivery modes which fulls point 4 of Chapter 1.3. Since the OMA BCAST specication is still of draft state and the Service Interactive Function has been a low priority part for some time, there are still issues and unclear points.

6.1
6.1.1

OMA BCAST Service Interaction Function issues

IMD issues

The XML-schema of the IMD [36] and the entire chapter about the Service Function in the OMA Mobile Broadcast Services [37], have been studied closely and a number of issues have been discovered. Some of the issues have already been pointed out by Thorsten Lohmar [45]. This chapter summarizes these problems. 1. Root element InteractivityMediaDocument has cardinality 0...N, this is not possible according to specications of W3C [48]. 2. Sub-element of Object called PartType lacks purpose, no attributes and no element content. This has been changed in a recent Change Request from the OMA forum. 3. If many media objects are dened within one MediaObjectGroup, Figure 5.2, the terminal needs to keep track of how to use the OnActionPointer. 39

40

Investigation of the OMA BCAST Service Interaction Function To which of the media objects in the MediaObjectGroup should it apply? For example, one MediaObjectGroup could contain a number of XHTMLpages referenced internally with ordinary XHTML-links. How should the terminal then know which of these XHTML-pages that is connected with the OnActionPointer. The placement of the OnActionPointer attribute is preventing the content producer from creating more advanced sessions of interactivity. 4. The way of structuring Objects in the MediaObjectSets is confusing. If the media objects should not be compressed then only one object is allowed per MediaObjectSet according to the specication. If only one media object can be rendered at the same time the complexity of interactive sessions is reduced. A XHTML page for example can not refer to pictures or stylesheets, since the MediaObjectSet should contain all objects that are to be shown at the time, of the same interactivity technology. On the other hand if the media objects are compressed, then a lot of small compressed archives are sent out to the user. 5. If the un-compressed alternative is used, the Content-Type attribute will give a hint about the content type, for example: application/xml+xhtml. If the MediaObjectSet contains a compressed archive le, the Content-Type attribute should be: application/x-gzip, see Figure 5.3. The terminal then needs to refer to the Object elements to gure out what kind of interactivity technology that is declared in the MediaObjectSet. 6. Inconsistency in the IMD. Attributes and elements have names like "ContentLocation", "Media_Object_Group" and "PartType". Why not decide a structured way on how to name elements and attributes? ContentLocation, MediaObjectGroup and PartType could be one alt. This has been changed in a recent Change Request from the OMA forum. 7. The actual rendering of the interactivity content is up to the terminal vendor. No information is provided in the IMD or InteractivityData fragment on how to show the content to the user. If a user is watching a TV-show, he or she would probably want to keep looking at the TV-show, and at the same time participate in the interactivity session. Maybe only a small part of the screen should be dedicated to the interactivity session. How this should be done is not within the scope of this thesis. 8. OMA BCAST discusses the use of SVG as interactive technology. SVG is good for presentational use but lacks functionality when it comes to user interaction. The use of SVG as interactive technology is not within the scope of this thesis, some dierent solutions to the problem can be found in [9].

6.1.2

Interactive session issues

One problem that give rise to questions is the way the interactivity session is described by the OMA specication, see Chapter 5.2.4. If the interactive technology

6.2 Preferred solution IMD

41

is XHTML and a simple poll is desired, the suggested alternative makes little or no sense. A simple scenario explains this: The user is presented with a number of objects, A, B & C, to chose from in the rst MediaObjectGroup. How should the user chose? A simple XHTML reference to the next cached XHTML page could be one alternative, if A is clicked a link refers to the next page. This is though not allowed, since every jump between MediaObjectGroups should be done with the OnActionPointer attribute according to the standard. Alternatively the OnActionPointer could be used, if the XHTML link of A is pressed the OnActionPointer lets the terminal know in which new MediaObjectGroup to look for the new referenced XHTML document. This will require more from the terminal than only a being simple proxy that handles user requests.

6.2

Preferred solution IMD

The two things that have raised the most questions are Point 3 and Point 4 of Chapter 6.1.1. According to the OMA there are two dierent ways to populate the IMD, either the use of a gzip archive le or un-compressed les, as discussed in Chapter 5.2.2. The structure of the IMD changes considerably depending on if the media objects are compressed or not compressed as described in Point 4 in Chapter 6.1.1. The second thing that can be seen as a limitation of the standard and the IMD is the problem with the OnActionPointer, Point 3 in Chapter 6.1.1. Therefore a slight modication of the XML-schema has been done in this demo application, see Chapter 6.2.1.

6.2.1

OnActionPointer attribute

The attribute OnActionPointer in element ActionDescriptor has been moved to the Object element in the demo application, see Figure 6.1 and Figure 6.2. This solution makes it possible to control the interactivity session even more and is an easy solution to the problem of point 3 in Chapter 6.1.1.

Figure 6.1. Modied Element: ActionDescriptor

42

Investigation of the OMA BCAST Service Interaction Function

Figure 6.2. Modied Element: Object

6.2.2

Compressed alternative

OMA Compliant According to the specication [37], each MediaObjectSet in a MediaObjectGroup could declare a gzip archive le. In this case all media objects dened in a MediaObjectSet are compressed into one gzip-archive, see Figure 6.3. The details regarding the media objects are then explained in the Object elements of the MediaObjectSet. Figure 6.3 is an example of how a IMD could be structured according to the OMA if the compressed alternative is selected. If the media objects consist of XHTML-pages and pictures, the problem with the OnActionPointer discussed in Chapter 6.1.1 will apply. References from XHTML-pages in one MediaObjectGroup to XHTML-pages in another MediaObjectGroup are not allowed, the specication lets you know that all referencing across MediaObjectGroups should be done with the help of the OnActionPointer. See Chapter 5.2 for further details regarding the structure of the IMD. This solution will end up in transmission of many smaller gzipped archive les. The MediaObjectSets will probably not consist of that many les, the gain of compressing a small number of objects with little data is questionable [9]. Alternative solution One alternative could be to have one archive le for all MediaObjectSets of the same technology, see Figure 6.4. With this solution the terminal will only be required to extract one le per interactivity session. The negative part with this solution is that the terminal will be forced to request the entire archive le, if the

6.2 Preferred solution IMD

43

broadcast transmission fails but in most cases the interactive content will be of small size.

Figure 6.3. OMA BCAST compressed alternative

6.2.3

Non-compressed alternative

In the non-compressed alternative described by the OMA, Figure 6.5, there should only be one media object per MediaObjectSet, and if no supplemental information is given by the Object element it can be omitted. Only Objects from one MediaObjectSet should be rendered at the time. That is the MediaObjectSet that has got the the highest relativePreference attribute and is supported by the terminal. Only one Object in each MediaObjectSet will not give a great user experience if for example XHTML is used as interactive technology. Alternative solution The requirement that only one media object can be described by the MediaObjectSet is not optimal when working with XHTML, since it often will require style sheets and pictures as well. To be able to present many media objects at the same time, this element also needs to be modied.

44

Investigation of the OMA BCAST Service Interaction Function

Figure 6.4. Modied compressed alternative

6.2 Preferred solution IMD

45

You could let the MediaObjectSet contain many Objects as for the compressed alternative. Then the Content-Type attribute of the MediaObjectSet makes no sense, Point 5 in Chapter 6.1.1. This is also clearly a violation of the standard. One alternative could be as shown in Figure 6.6, that is keep one Object in each MediaObjectSet but declare one MediaObjectSet for each media object. Many MediaObjectSets can then be rendered at the same time, e.g. one containing a XHTML-page and another containing a jpeg-le.

Figure 6.5. OMA BCAST non-compressed alternative

Figure 6.6. Alternative non-compressed alternative

46

Investigation of the OMA BCAST Service Interaction Function

6.2.4

Other Scenarios

Live updates of the current number of votes Point 1 in Chapter 6.1.1 could actually allow a nice feature to the interactivity session. If it is possible to specify how the IMD content should be rendered on a screen, this could be used to declare many IMDs to one interactivity session. A common groupID attribute could be set in a number of IMD instances, which together declare a complete interactive session. This is discussed in point 7 in Chapter 6.1.1. The following is a possible scenario: The IMD consist of two or more instances of the IMD structure. One IMD declares a vote session as it has been discussed earlier and the second IMD is only used to keep track of the current number of votes. This second IMD could then have a MediaObjectGroup with an ActionDescriptor with the updateFlag attribute set to true. If the validity time of this second IMD is short, the terminal will listen for new updated versions of the IMD and continuously present the current vote result to the user. Chat session The OMA documents also suggests that the Service Interaction Function could also be used to implement a chat session. The user can submit a message which will be displayed to everybody that watches the channel. This can probably also be implemented with the use of an IMD with an updateFlag set to true. Then all clients watching the channel keep receiving up-versioned IMDs with the new chat messages which are shown on the screen. In what format or how these chat messages should be sent from client to server and from server to client is not specied by the OMA. One simple solution could be to let the user write the message in a SMS or MMS template that is sent to the server. The server receives the message and redelivers it as a media object, XHTML, SVG etc, to all terminals which renders the new chat messages.

6.3

Preferred solution Interactivity session

The OMA specication explains that a MediaObjectGroup is a ...grouping of MediaObjectSets, which serve the same purpose during interactivity, e.g. as a starting MediaObjectSet, as a MediaObjectSet to be shown after action was taken or to be shown after time-out was reached . . . [37]. This could allow a number of interactivity screens to be grouped together and form a MediaObjectGroup and still comply with the OMA BCAST. One MediaObjectGroup can contain more than one XHTML document. The XHTML pages within the MediaObjectGroup could then link to each other and enable even more interesting interactivity sessions. Problems arise when having many media objects in one single MediaObjectGroup, discussed in Chapter 6.2.1. The OnActionPointer attribute lacks reference to individual objects and is only connected to the entire MediaObjectGroup. If there are many objects within the MediaObjectGroup this becomes

6.4 Conclusions

47

a problem since the terminal can not possibly know which of the objects that the OnActionPointer refers to, if the user has taken action. Sometimes the program should follow links inside the XHTML page and sometimes it should switch to another MediaObjectGroup using the OnActionPointer. The solution to this has been discussed earlier, the OnActionPointer attribute is for this application moved into the 6.2 element, read more in Chapter 6.2.1. Another problem with the interactive session was discussed in Chapter 6.1.2. Due to this some slight changes have been made and the boundaries of the specication are pushed a little in the next chapter.

6.3.1

Proposed solution

The OMA suggestion for an interactivity session has been described in Chapter 5.2.4. In the implemented demo application the session is modied, see Figure 6.7. The session structure of the modied solution allows the following scenario for an interactive session. MediaObjectGroup 1 The user is presented with a welcome screen which presents the session to the user and lets the user know about costs and other related information. If the user reacts within the inputAllowedTime the onActionPointer let the terminal know which MediaObjectGroup to present next. MediaObjectGroup 2 The user has chosen to participate. A selection of some kind is presented, dierent pictures for example, the user decides on how to vote and clicks an ordinary XHTML-link. No onActionPointer is declared for the Object representing the XHTML page in the IMD. The link presents another XHTML page and a conrmation screen is shown. This new page is a conrmation page, the user is presented with cost information and if he/she wishes to send the vote, a XHTML-link sends an HTTP-get request. This second page has got an onActionPointer that refers to the third and last MediaObjectGroup in the session. MediaObjectGroup 3 A thank you and good bye page is shown. In all the above cases the onTimeOutPointer refers to the next MediaObjectGroup if the user does not act within the inputAllowedTime.

6.4

Conclusions

To be able to deliver a rich user experience the alternative solutions of Chapter 6.2.2 and Chapter 6.2.3 are implemented in the demo application. It will also follow the proposed solution of an interactivity session described in Chapter 6.3.1. The Live Update functionality described in Chapter 6.2.4 is not implemented due to limitations of the MAD FLUTE implementation, and can be seen as a suggestion on extended functionality of the OMA BCAST Service Interactive Function.

48

Investigation of the OMA BCAST Service Interaction Function

Figure 6.7. Proposed interactive session

6.5 Summary

49

6.5

Summary

The OMA BCAST Service Interaction Function is still of draft version. Some issues that were discovered during the work with the thesis were explained in this chapter. Solutions to many of the problems were presented, including some alternatives to the interactive session dened by OMA. Modications that are done to the standard to give a better user experience were also explained. Two other possible features with the standard were explained and described.

50

Investigation of the OMA BCAST Service Interaction Function

Part III

Implementation

51

Chapter 7

System Architecture Description Demo application

This chapter describes the objectives and the structure of the Demo application that has been implemented. This chapter fulllls point 2 of Chapter 1.3.

7.1

Architecture overview

Figure 2.2 and Figure 2.3 describes the overall architecture of some dierent business models that could be used in the system. For this test and demo application the complexity of the system has been reduced down to a single server/client system, as can be seen in Figure 7.1.

7.2

General description

To be able to evaluate the specication fully, a demo application has been developed in Java/J2EE. The application is divided into two main parts, a client and a server. The server is delivering IMD and media objects to the clients. The server is also responsible for handling feedback from the client, feedback is sent from client to server using the HTTP protocol. The IMDs are structured according to the discussion in Chapter 6.2. The interactivity session enabled and delivered by the application has been explained in Chapter 6.3. To limit the complexity and scope of the implementation, user interactivity is limited to a poll using XHTML webpages and a stylesheet (CSS). Notes on how to install the application on a regular PC can be found in [26]. 53

54

System Architecture Description Demo application

Figure 7.1. Structure of the demo system

7.3

Objectives

At the beginning of the project a number of requirements were identied for the application. Specic requirements where dened for client and server separately.

7.3.1

Client objectives

The client should be able to receive both the IMD and the media objects via FLUTE, the media objects can be both compressed and noncompressed. The interactivity content should be presented in a browser, IF the terminal supports the interactivity content technology. If parts are missing, the client will be able to request these missing parts using HTTPPOST. Feedback to the server should also be enabled using HTTPPOST. The client should be developed in Java/J2EE, the main functionality will be to receive, store and render the interactive content at the right time. Implementation objectives The client should be able to: Receive the IMD via FLUTE Receive compressed media objects via FLUTE and decompress them. Request compressed and non-compressed media objects via HTTPPOST. Present the interactivity content. XHTML, pictures .css etc...

7.4 Assumptions

55

If no user activity within a certain amount of time the interactivity content should be destroyed according to the standard [37]. Send the vote feedback to the server (HTTP-Post).

7.3.2

Server objectives

The server should be able to send interactivity content via FLUTE and HTTPPOST, compressed and not compressed using Gzip [16]. The client(s) may request missing media objects using HTTP-POST and the server must be able to deliver these. The feedback that the server receives from the client(s) should be presented on the server side. Some sort of schedule mechanism for sending out interactivity content is probably also needed in the server. Implementation objectives The server should be able to: Broadcast the IMD via FLUTE. By scheduled transmissions. Choose between two broadcast distribution alternatives: IMD and compressed archivele with the declared media objects sent in one single FLUTE session as described in Chapter 6.2.2. IMD and declared Media Objects sent un-compressed in one single FLUTE session as described in Chapter 6.2.3. Send media objects on Client request (HTTPrequest). Present the client feedback Keep a persistent log of the vote results. Send updated vote results to clients.

7.4

Assumptions

One major assumption ot this demo application is that the terminal already has tuned in the correct FLUTE channel, and therefore is able to receive interactive content. In a real situation the FLUTE parameters would also already be initialized, since the interactive content usually is received over the same channel as the service it belongs to. The client is assumed to have the same perception about time as the server. In this application this is maintained by the third party library Apache Commons - net, see Chapter 7.7.1.

56

System Architecture Description Demo application

The content is manually created, i.e. the IMD is already created with the correct references to media objects. The media objects, XHTML pages, pictures and stylesheets are also pre-fabricated. The feedback sent from client to server is not containing any IMD specic information as suggested in Chapter 6.2 but only the choosen object (picture).

7.5

Use Cases

This chapter describes use cases from the perspective of an end user and of the operator. Two main use cases are studied, see Figure 7.2.

Figure 7.2. Use cases

7.5.1

Actors

Table 7.1 contain a list of actors. Actors can take one or several roles if needed to interact with the system.

7.5.2

Use case description

As seen in gure 7.2 there are two main use cases. A third one can also be identied, Prepare Interactive Content see below, but in the demo application this is done manually and will therefore not be dened as a use case.

7.6 System use cases Actor End user Content provider Roles Always a legal consumer of the interactivity content provided by the Interactivity system Content Manager: an non-technical entity for the management of content to the IPTV or Mobile-TV provider. Technical : Technical entity responsible for the creation and delivery of content to the IPTV provider. Administrator/Technical: Is responsible for managing the technical aspects (of the network?)
Table 7.1. Actors

57

Operator

Distribute Interactive content: The use case identies the activities needed to deliver the interactive document to the end-users and handle feedback from them. Interact: The end user is presented with an interactivity interface. The interface will provide the means to interact in the form of a poll with a few choices. Prepare Interactive Content: Identies the relationship between the Interactive Content developer/provider and the operator/content handler. Identies the activities needed to prepare the interactive content (IMD and Media Objects) that is delivered by the content developer/provider for distribution.

7.6

System use cases

The sections below will present the dierent use cases dened in the previous chapter. Each function is described by an activity chart, their intent is to provide a conceptual understanding of the steps needed for the execution of the function independent of the underlying realization.

7.6.1

Distribute Interactivity Content

The ow chart of the following use case is found in Figure 7.3 and a sequence diagram in Figure 7.4. Pre-conditions The IMD and media objects are constructed manually and put in the correct folder. The decision whether to send the media objects as a compressed archive

58

System Architecture Description Demo application

Figure 7.3. Flow Chart: Distribution of Interactive Content

7.6 System use cases

59

le or not is stated in a settingsle. For more information, see the manual [29]. Use case 1. Set validity time in IMD The validity time in the IMD is set according to information in a settingsle. validFrom and validTo are set by the content provider in the settingsle as delays in units of milli seconds. 2. IMD to Broadcaster Provide the Broadcaster (FLUTE sender) with the id of the IMD to send. 3. Construct compressed archive le to send If the compressed alternative is chosen, the compressed archive le is created using the structure of the IMD. 4. IMD and compressed archive le to Broadcaster Deliver the IMD and archive le to the broadcaster. 5. Broadcast Broadcast the IMD and media objects to the clients using FLUTE.

Figure 7.4. Sequence Diagram: Distribution of Interactivity Content

60

System Architecture Description Demo application

7.6.2

Interact

Pre-conditions The terminal is aware of which FLUTE channel to listen to and how to receive the interactivity content. Use case Figure 7.5 depicts this use case and Figure 7.6 describes the sequence diagram. 1. Cache interactive content The client retrievs the Interactivity Media Document via FLUTE. The media objects are received in the same FLUTE session either as a single compressed archive le or uncompressed. Since only one set of media objects can be rendered at the same time by the terminal, a simple ltering process is done in this stage as well only the Media Object Set with the highest relative priority that is supported by the terminal is cached. 2. Request missing les If the client did not receive all media objects when broadcasted these can be requested from server. A return path of this type will probably not be present for a mobile client so this alternative will represent IPTV. 3. Render Interactive Content The Interactivity handler within the client will trigger the rendering of Interactive Content based on the activation time provided in the IMD. 4. Deliver feedback The interactivity response from the end user is returned to the server using HTTP-POST. (TV-Controller receives feedback and forwards it to the Feedback collector) 5. Process feedback The received feedback is processed by the Feedback Collector, votes are stored and counters are updated. 6. Regenerate interactive content Regenerate or modify the media objects that needs to be altered or replaced due to the received feedback. 7. Submit interactive content Deliver the updated media objects.

7.6 System use cases

61

Figure 7.5. Flow Chart: Interact

62

System Architecture Description Demo application

Figure 7.6. Sequence Diagram: Interact

7.7

Third party products

The external libraries and the external programs used by the program are presented, all of them of open source type.

7.7.1
- net

Apache Commons
The NTP (Network Time Protocol) classes in the net package are used to support the requirements of time handling in OMA BCAST. Hence no manual update of time in the client is done, it is not within the scope of this application. The PC application is simply trusting this library to keep track of the correct time.

- http client The http client package gives the client the functionality needed for connecting to and interacting with the server over the interaction channel.

7.7.2

Flying Saucer R6

Java library that enables XHTML rendering within a Java program, this is used to present the Interactivity Content to the end user.

7.7.3

Flute implementation, MAD-FLUTE

The MAD-FLUTE implementation of the FLUTE/ALC-protocol is implemented in C++ and is used to broadcast the interactivity content from the server to the clients, and also to receive the interactivity content on the client.

7.8 Content creation

63

7.7.4

Java Architecture for XML Binding (JAXB)

This library is used to create Java objects from XML les.

7.7.5

Java Tar

Library for bundling many les togheter as one single archive le of .tar-type. This is used when interactivity content should be sent compressed to the users.

7.7.6

JDOM

JDOM is used in the client to parse the received XML-les to extract information.

7.7.7

Jetty

Jetty is a servlet container that is used because of its easy implementation with the build tool Maven 2. Jetty is never referred to in the code, only by Maven. Other servlet containers (such as Tomcat/Weblogic) should work ne as well, even without changing any code.

7.7.8

Maven

Maven is a build tool used to deploy the webserver and build the Java code.

7.8

Content creation

The dierent media objects used for this demo application is pre-made along with the two dierent IMDs, one IMD is for the compressed alternative and one IMD is used for the non-compressed alternative. The interactivity content is simply stored in a folder, stated in a settingsle as described in the manual [29]. The interactivity content consists of a number of XHTML-pages with external Cascading Style Sheets, CSS, and pictures.

7.9

Logical view

This section describes the logical modules needed to provide the interactive feature for the demo application. It also describe how the modules relate to each other and their roles.

7.9.1

System overview

An end user that wants to participate in a interactive session uses a client application on his/her terminal. The system on the operator side would in a real system consist of many dierent modules as described in Chapter 2.3. For this application and in this document the interactive system on the operator side is know simply as the server.

64

System Architecture Description Demo application

Figure 7.7. Overview of the information ow for the server-client system.

There are two channels for information exchange between the client and the server as explained in Chapter 4.2. The interaction channel is used by the client to request missing media objects and send feedback. This channel of communication could in a real system be realized by for example SMS, MMS or HTTP depending on if the client application is a handheld device or a set-top box. The second channel of information is the broadcast channel which is realized using the FLUTE protocol, see Appendix B.1.2. The session is structured as the prefered solution in Chapter 6.3.

7.9.2

Server

Overview The server consists of ve main modules Broadcaster, Broadcast Scheduler, Feedback Collector, Media Content Manager and the TVController, see Figure 7.8. The values validFrom and validTo are inserted into the current IMD right before it is sent to the client(s). The values represent the time window of which the IMD is valid in milliseconds, calculated from start of delivery.

Figure 7.8. Inter-process communication sketch server

The Broadcaster module is responsible for broadcast transmissions of interactive content. The Broadcast Scheduler makes sure that the content is broadcasted at the right time. The Feedback Collector takes care of the client response in terms of vote results. The Media Content Manager handles the interactive content. TV-

7.9 Logical view

65

Controller is the part that communicates with the terminals, it represents the interactive channel between clients and server. Broadcaster The protocol for broadcast transmissions, FLUTE [23], is implemented with the help of the 3rd party product MAD-FLUTE [28]. This implementation of FLUTE lacks Java API so the Broadcaster module executes one instance of the MADFLUTE runnable to broadcast the les that are declared in the IMD. The Broadcaster broadcasts the desired content one time and then the broadcast part of the application dies. Broadcast Scheduler The Broadcast Scheduler makes sure that the interactive content is broadcasted at the right time. The scheduling information is collected from the broadcast settings le. In this settings le the number of milliseconds from start of program to broadcast execution is set. Feedback Collector The Feedback Collector creates vote objects when feedback is received, it is also capable of saving vote results to a text le for persistency. Every time feedback is received the Feedback Collector orders the Media Content Manager to update the version number of the IMD and change the current vote result in the interactivity content. Media Content Manager The creation of media content and the IMD is done manually. All later modications of the interactivity content are performed by the Content Manager. A modication could be to update the version number in the IMD or to change the current number of votes in a XHTML document. The update of media content, IMD version and vote result, is done in a rather of hard coded fashion in this application and is only meant to show how updates of some media object could look like. TvController The TVController is implemented as a webserver which handles HTTP POST requests from the terminals. The interface towards the clients allows for four dierent types of requests: 1. IMD The terminals can request the latest IMD for test purposes. 2. Media Object Set

66

System Architecture Description Demo application The terminals can make requests for MediaObjectSets. If the terminal receives interactive content via broadcast transmissions this is used to fetch non-received objects. 3. Feedback The standard is not specifying the format of the feedback when using a HTTP return path. In this application the name of the vote is returned to the TVController. When feedback is received it is forwarded to the Feedback Controller which stores the vote.

If the TVController is accessed from a web browser (HTTP GET) an XHTML page is returned with information about the server and the current vote results. The URL to the page is http://a.b.c.d:8080/Webserver, a,b,c and d is the ip-address of the server.

7.9.3

Client

Overview The client has got four dierent modules, see Figure 7.9. The Communication block handles all contact with the server. Data Handler is responsible for parsing and managing the interactive content. To present the interactivity session to the user there is a Graphical User Interface block, GUI. The Model block contains the actual structure of the cached interactive content.

Figure 7.9. Inter-process communication sketch client

The receival of broadcast transmissions is obtained using the same FLUTE implementation as on the server side, MAD-FLUTE [28], but in receiver mode. Communication This block is responsible for all communication with the server. The communication block contain functionality for handling the objects received over broadcast. It also contains classes and methods for requesting certain Media Objects using HTTPPOST and sending feedback back to server. The broadcast channel is implemented using the MAD-FLUTE implementation 7.7.3. An instance of this program is started in receiver mode which listens

7.9 Logical view

67

to a specic broadcast channel. The receiver is capable of receiving one FLUTE session and then it needs to be restarted. This limitation is due to that the control of an externally running program from inside a Java implementation is rather limited. Data Handler When interactivity content is received this block makes sure that the content is parsed using JDOM 7.7.6 and the IMD information is cached as java objects. It has also got a state mechanism which keeps track of were in the interactivity session the user is. User Interface Consists of a graphical user interface, presents the interactivity session to the user and manages user input. In the rst screen, Figure 7.10 the user is informed about the interactivity session. If no button is pressed within time dened by the inputAllowedTime attribute, the session is discarded. This means that the OnTimeOutPointer related to that MediaObjectGroup is used and the referenced MediaObjectGroup is presented to the user, Figure 7.14.

Figure 7.10. First screen of interactivity session, rst media object group.

The end user clickes the button on the GUI to participate in the interactivity session. By doing so the OnActionPointer of the Object is pointing out the next MediaObjectGroup, and the MediaObjectSet with the highest relativePreference is presented to the user. The rst screen of the second MediaObjectGroup allows the user to choose from three dierent pictures, Figure 7.11. The numbers inside the brackets are the current number of votes. When the user has decided on which of the pictures that is the most beautiful, the link is clicked and the next screen is presented,

68

System Architecture Description Demo application

Figure 7.12. Note that this time no OnActionPointer is followed and the link refers to another Object in the same MediaObjectGroup. In this screen the user is asked to conrm the selection, when the conrm link is clicked the feedback is sent to the webserver. The OnActionPointer refers to the next MediaObjectGroup and again the MediaObjectSet with the highest relativePreference is presented, Figure 7.13.

Figure 7.11. Second screen of interactivity session, second media object group.

Figure 7.12. Third screen of interactivity session, second media object group.

Model This block consists of the Java model of the IMD, used to cache the IMD in memory. The classes are autogenerated by the Java Architecture for XML Binding

7.9 Logical view

69

Figure 7.13. Fourth screen of interactivity session, third media object group.

Figure 7.14. Screen shown if the session times out.

70

System Architecture Description Demo application

library 7.7.4 from the IMD XMLschema upon build with Maven. The XML schema has been modied according to the discussion in Chapter 6.2.

Options The client has got two dierent ways of retrieving the IMD and the media objects, over the broadcast channel using the MAD-FLUTE external program but also using a regular HTTP-request. The HTTP-request for an IMD is initiated by a mouse click on the GUI, the user then have the choice of ordering the interactivity content as a compressed archive le or not, Figure 7.15.

Figure 7.15. Http

The client settings le enables the application to switch between pulling missing les or not. The option determines if the client should pull a missing le from the server using a HTTP POST-request. If a le belonging to the current interactivity session is not received correctly after a broadcast transmission, it is requested from the webserver using HTTP-POST. The MAD-FLUTE implementation can be set to simulate packet loss as well to test this functionality. Read the application manual [29] to see details about how to make the dierent settings.

7.10 Summary

71

7.10

Summary

Objectives and expectations of the implementation stated in the begining of the work is explained. The structure of the implemented program is given along with use cases and sequence diagrams which describes the wanted functionality.

72

System Architecture Description Demo application

Part IV

Conclusions

73

Chapter 8

Result and discussion

The end result of this thesis work fullls the two objectives stated at the early start of the thesis in order to investigate the OMA BCAST Service Interaction Function. The rst part was to make a theoretical investigation of the specication. The second part was to implement an application, the objectives for both the server and the client were described in Chapter 7.9.2 and Chapter 7.9.3 respectively. Letting the IMD control the actual interactivity session also raise questions. The structure of dividing the interactivity objects into media object groups controlled by the action descriptor in the IMD feels complex. It might be enough to let the IMD declare the dierent les and interactivity technologies and not use the IMD to describe the actual session. By omitting the session description in the IMD the terminal is still able to accept only supported formats and the interactivity sessions could be implemented with the use of ordinary XHTML, SVG etc. technologies. In this way a browser could be used to render the complete session since XHTML and SVG is most likely to be used for interactivity sessions. Since the OMA BCAST Service Interaction Function is independent of the underlying network it is probably possible to use the specications even in a broadband environment with some modications. IPTV will probably not use the ESG in the same way as in mobile television, but still some sort of framework for connecting the interactivity with the service needs to be developed. IPTV has also got higher bandwith on the return channel which makes it possible to easier request missing parts and interact with the server. But the main idea is still to receive as much as possible over the broadcast channel to avoid massive synchronous requests of interactive content from the end users. The OMA BCAST specications provides a rich user experience depending on the receiver device. The structure of the ESG and IMD enables description of many formats, dierent A/V streams in the ESG and dierent interactivity solutions in the IMD. The server network could broadcast many types of technologies and the receiver application, mobile phone or STB, only accepts the content that it can render the best. If one wants to create an application that enables a rich user interactivity experience any time soon, the OMA BCAST solution might not be the right way to go. It is not only a huge organisation were decisions take time, the standards 75

76

Result and discussion

developed are often large and generic. The implementations will grow big if they should be fully compliant with the standard. The specications can be interpreted in many dierent ways as seen during this thesis work. On the other hand, a solution that supports a global standard will reach a larger audience once up and running.

Chapter 9

Future studies
The use of Scalar Vector Graphics (SVG) as interactive technology would denitely be something for further studies, SVG allows for nicer presentations. The user interaction part theen needs to be studied more. There support of forms and other interactivity enablers in SVG needs to be studied. If SVG should be used on handheld devices, the prole SVG Tiny should also be studied. To be able to deliver the interactive content in any form the client needs to know how to render the content. This is of extra importance when not using the pre-fabricated templates of SMS or email but instead XHTML, SVG etc. Should a simple split screen appear and show the interactive content in parallel with the service? Or should the interactive content be overloaded with its service? Like a text scroll on the bottom of the screen or the current number of votes in a poll in a corner of the screen. Some eort to determine how to render the interactive content to make it more unlike the usual browser is probably needed. Maybe there should be parameters specifying the position to render the object included in the IMD.

77

78

Future studies

Bibliography
[1] ATSC. Advanced Television Systems Committee Forum, http://atscforum.org/loader.html [2] ATSC ATSC Standard: ATSC Interaction Channel Protocols, http://www.atsc.org/standards/a_96.pdf, visited 20070212 [3] WorldDAB. DAB forum, http://www.worlddab.org/ [4] DigiTAG. Television on a handheld receiver broadcasting with DVB-H, http://www.digitag.org [5] DVBH. DVBH Forum, http://www.dvb-h.org [6] DVBT. DVB, http://www.dvb.org [7] EBU. European Broadcasting Union IPTV - a dierent television?, http://www.ebu.ch/CMSimages/en/online_30_e_IPTV_tcm6-46309.pdf? display=EN, visited 20070508 [8] EBU. Will Broadband TV shape the future of broadcasting?, http://www.ebu.ch/en/technical/trev/trev_302-kozamernik.pdf? display=EN, visited 20070508 [9] Ericsson MTV&V Interactivity Pre-study, Ericsson Internal, 3/03632/FCP 116 171 UEN [10] Elsevier Interactive TV Standards A Guide to MHP, OCAP and JavaTV, S. Morris and A. Smith-Chaigneau, ISBN: 0-240-80666-2 [11] Ericsson Interactive Stream Linking Technical report for IPTV, Ericsson Condential, 5/0363FCP 116 180 UEN [12] ETSI. TV-Anytime Specications TS 102 822, http://www.etsi.org, visited 20070131 79

80

Bibliography

[13] ETSI. Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H) EN 302 304 V1.1.1 (2004-11), http://webapp.etsi.org/action/PU/20041109/en_302304v010101p.pdf, visited 20070208 [14] Gerard Faria & Fabio Scalise DVBRCT: A Standard For Interactive DVBT, http://www.broadcastpapers.com/whitepapers/ DVB-RCT-A-standard-for-interactive-DVB-T.cfm?objid=32&pid= 235&fromCategory=53, visited 20070211 [15] IETF. RFC 1321 The MD5 Message-Digest Algorithm, R. Rivest, April 1992 [16] IETF. RFC 1952 GZIP le format specication version 4.3, P. Deutsch, May 1996 [17] IETF. RFC 2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols, A. Mankin et al, June 1998 [18] IETF. RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation, M. Luby et al, December 2002 [19] IETF. RFC 3451 Layered Coding Transport (LCT) Building Block, M. Luby et al, December 2002 [20] IETF. RFC 3452 Forward Error Correction (FEC) Building Block, M. Luby et al, December 2002 [21] IETF. RFC 3569 An Overview of Source-Specic Multicast (SSM), S. Bhattacharyya, July 2003 [22] IETF. RFC 3644 Policy Quality of Service (QoS) Information Model, Y. Snir et al, November 2003 [23] IETF. RFC 3926 FLUTE - File Delivery over Unidirectional Transport, T.Paila et al, 2004 [24] ISDB. Integrated Services Digital Broadcasting, http://www.dibeg.org/PressR/chile2006/chile%20seminar-all.pdf ,visited 20070212 [25] IP Datacast. IP Datacast Forum FAQ, http://www.ipdc-forum.org/about/faq.html, visited 20070202 [26] Installation notes Installation of OMA BCAST Service Interaction Function demo application, Karl-Johan Lundkvist, 2007

Bibliography

81

[27] LIF Location Working Group, http://www.openmobilealliance.org/tech/affiliates/lif/lifindex. html , visited 20070201 [28] MAD-FLUTE. MAD-FLUTE implementation, http://atm.tut.fi/mad/ [29] Manual Manual to OMA BCAST Service Interaction Function demo application, Karl-Johan Lundkvist, 2007 [30] Markus Lindqvist. Its the business, DVBScene, Issue 19, September 2006 [31] MediaLab TeliaSonera. Mobile Broadcast/ Multicast Service (MBMS) White Paper, www.medialab.sonera.fi, August 2004 [32] MHP. Multimedia Home Platform, http://www.mhp.org, Visited 20070214 [33] The MHP Knowledge Project (MHP-KDB). The MHP-Guide A comprehensive Guide to the Multimedia Home Platform, the underlying technology and possible uses, http://www.mhpkdb.org, Visited 20070315 [34] Open Mobile Alliance. Enabler Release Denition for DRM V2.0 OMAERELD-DRM-V2_0-20060303-A, http://www.openmobilealliance.org [35] Open Mobile Alliance. iMobicon 2006 OMA Broadcast Enabler Release 1.0 Sungoh Hwang, http://www.openmobilealliance.org/docs/0906_IMobicon_ OMABCASTSpec.pdf, Visited 20070214 [36] Open Mobile Alliance. Interactivity Media Document OMA-SUPXSD_bcast_si_interactivitymedia-V1_0-20061214-D.xsd , http://www.openmobilealliance.org [37] Open Mobile Alliance. Mobile Broadcast BCAST_Services-V1_0_0-20061229-D, http://www.openmobilealliance.org Services OMA-TS-

[38] Open Mobile Alliance. Open Mobile Alliance Overview OMA-Public Overview-2004-03.pdf, http://www.openmobilealliance.org/about_OMA/index.html, visited 20070205

82

Bibliography

[39] Open Mobile Alliance. Service Guide for Mobile Broadcast Services OMATS-BCAST_Service_Guide-V1_0_0-20070104-D, http://www.openmobilealliance.org [40] Pablo Ceasar. A Graphics Software Architecure for High-End Interactive TV Terminals, ISBN 951227888X (electronic version), 2005 [41] Peng Li and Qi Cheng. Performance analysis and test of the DVB-RCT system, Master Thesis, Department of Electronics, Computer and Software Systems (ECS), School of ICT, Royal Institute of Technology (KTH) Stockholm, 03/2006 [42] QUALCOMM. F LOT M Technology Overview, http://www.qualcomm.com/mediaflo/products/flosystem.shtml, ited 20070213 [43] Simon Mason. Mobile TV results from the DVB-H trial in Oxford, EBU Technical review, April 2006 [44] SUN Developer Network. Java TV API, http://java.sun.com/products/javatv/index.jsp,visited 20070214 [45] Thorsten Lohmar BCAST compliant Interactive Server Enabler, Ericsson Internal, 2006 [46] Toni Paila. OMA Mobile Broadcast Services, Slides http://www.tml.tkk.fi/Studies/T-111.590/2005/lectures/ paila.pdf, visited 20070205 [47] WAP Forum. WAP Forum, http://www.wapforum.org/ , visited 20070201 [48] W3C. Extensible Markup Language (XML) 1.0 (Fourth Edition), http://www.w3.org/TR/xml/ , visited 20070228 Vis-

Part V

Appendices

83

Appendix A

OMA BCAST Service Enabler

A.1 OMA BCAST Service Enabler Service Guide Data Model

The OMA BCAST Service Enabler is a bearer agnostic application layer for broadcasted services of kinds. These services could for instance be mobile television, interactive games or software updates. The bearer aspects of mobile television and other services are already well dened with technologies like DVBH and 3GPP MBMS. The OMA BCAST Service Enabler covers broadcast over both cellular networks, 3GPPMBMS, and over regular IP broadcast networks, such as DVB H. The receiving terminals are all dierent kinds of terminals, although handheld clients are the main target [35]. The OMA BCAST Service Enabler consist of several functions such as Service Guide, Content Protection, Service Protection, Interaction, Purchase and Payment, File delivery and Service provisioning. The idea is to distribute content using two channels: a broadcast channel and an interactive channel. The broadcast channel will enable transmission of streaming video, i.e. television, but also delivery of the ESG and other suitable services such as software updates. The Broadcast channel should be realized using an IP based broadcast network such as DVB-H or MBMS. The interactive channel is realized with GPRS, MMS, SMS etc. and can be used for user feedback. OMA BCAST Service Guide Data Model The Electronic Service Guide is one of the most central parts of the OMA BCAST Service Enabler since it is the actual framework on which all the information about the available services reside. Figure A.1 depicts the Data Model of the OMA BCAST ESG. The boxes in the gure are referred to as fragments of the Service Guide, the fragments contains 85

86

OMA BCAST Service Enabler

Figure A.1. OMA BCAST Service Guide Data Model [39].

A.1 OMA BCAST Service Enabler Service Guide Data Model meta-data and information about the service represented as XML. ServiceGuideDeliveryDescriptor

87

The ServiceGuideDeliveryDescriptor (SGDD) declares the structure and availability of Service Guide fragments within a Service Guide delivery. The terminals can check the received fragments against the SGDD to determine if all fragments have been received, it also provides the grouping of related Service Guide fragments. Service The Service fragment describes a bundle of content items, that together form a complete data structure of information about a service. The service could be delivered using a broadcast channel or an interactive channel, or both. A service could for instance be a TV-Channel, a VOD service or a multiplayer game. The Service fragment is the central part of the Service Guide when describing a service. It is referenced by many of the other fragments and together with these fragments the terminal can extract information about the service. Some of this information can be shown to the user, for example the EPG. Schedule This fragment denes when the content of the service is accessible to the terminal. It always always references the Service fragment. It can also dene the timeframe of which content items declared in a Content fragment or Interactivity Objects declared in a InteractivityData fragment are valid. Content This fragment gives a detailed description of a content item, a content item can be a TV-show that the service refers to. It can contain information about targeted user group, genre and parental rating as well as type, description and language. PurchaseItem Represents a group of one or more services or one or more content items oerd to the the end user. This group of content could be free, for subscription and/or purchase. The PurchaseItem can be referenced by PurchaseData fragments to give extended information. PurchaseData This fragment contains information about all the available pricing information for the referenced PurchaseItem. Information regarding promotional activities may also be included in this fragment.

88 PurchaseChannel

OMA BCAST Service Enabler

The PurchaseChannel fragment contains information about how to obtain the items were dened in the PurchaseData fragment. Access This fragment describes how to access the service during its valid time intevall. The same service can be referenced by many dierent Access fragments enabling dierent access methods. If there are dierent languages for a TV-show the user can gain access to the prefered selection, using a specic Access fragment. This fragment also contain information intended for the terminal like information about what kind of requirements that are put on the terminal to be able to gain access to and render the content. SessionDescription Provides session information for accessing a service or content item. The fragment contains parameters for IP addresses, transport protocols and other network related information. PreviewData This fragment can include previews and free samples of arbitrary format to give the end user a general idea of what the service or content is about. InteractivityData The InteractivityData contains information about interactive sessions closely related to the broadcast service. An interactive service could be a chat or poll related to the broadcast content. This fragments refers to the Interactivity Media Document (IMD) which is discussed in detail in Chapter 5.2. The IMD declares these interactivity sessions thoroughly. The ESG can consist of many services, all of which have this structure of meta-data. A typical structure of the ESG could be to have a Service fragment representing a broadcasted TV-channel, then there would be schedule fragments and content fragments for each TV-show. If there are multiple languages available for the TV-show then there would have to be multiple access fragments related to each show to describe how to watch the show with the preerd language. PreviewData could contain a logo of the TV-channel or a small advertisement clip.

Appendix B

File delivery protocol

B.1 File Delivery over Unidirectional Transport FLUTE

Since the le transfer protocol Flute [23] probably will be the le delivery protocol of choice when broadcasting data, it is discussed in more detail in this chapter. The data could consist of data les or non streaming video or audio content. FLUTE extends Asynchronous Layered Coding (ALC) protocol [18], which is a combination of a Layered Coding Transport (LCT) building block [19], a FEC building block [20] and a multiple congestion control building block compliant to [17].

B.1.1

RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation

ALC denes how to deliver arbitrary objects of any size over a broadcast channel or a multicast channel in a reliable way, using IP multicast as the base network service. The channel consist of a combination of the sender IP address and a channel address. It is possible due to a combination of the LCT building block [19], FEC building block [20] and a multiple rate congestion control building block [17]. Due to the lack of a fully dened congestion control scheme for Internet multicast, RFC3450 is still labeled as Experimental. The information ow in ALC is from sender to receiver(s), using UDP. The UDP packet header is followed by the default LCT header, FEC payload ID and then the actual payload. A Transmission Session Identier (TSI) must appear in every LCT packet header, the TSI togheter with the sender IP-address is a uniqe identier of the session. The Transport Object Identier (TOI) must also be present in the LCT packet header, this allows the receiver to identify to which object the packet belong. ALC supports both the traditional Any-Source Multicast (ASM), many-tomany, and the Source-Specic Multicast (SSM) [21], one-to-many or few-to89

90

File delivery protocol

many. Connectivity between receiver and sender is not required, it can be applied to the Internet, LANs, Wireless networks etc. A session in ALC is dened in the same way as for LCT: An ALC session comprises multiple channels originating at a single sender that are used for some period of time to carry packets pertaining to the transmission of one or more objects that can be of interets to receivers [18]. The specication only talks about a single sender, eventhough it supports ASM. Delivery of packets belonging to one object from many senders is enabled by setting up one session for each sender. The sender generates packets based on the objects that should be delivered within the session and then it sends the packets with a specic bit rate on the pre-dened channel(s). The receiver then joins the channels for the current session, congestion control is performed by adjusing the set of joined channels. In Mobile-TV or regular IP datacasting this will probably not be a problem since the congestion control can be managed before the actual radio transmission in a controlled manor. ALC denes a number of parameters that a receiver needs to know before joining a session but it does not dene how the receiver should obtain the information. It also supports a number of service models, the most interesting is the Push Service Model which allows a sender to deliver objects to a selected set of receivers. The receivers retrive a description of the session in some way and then join the channel when the delivery is initiated. When enough packets are received to reconstruct the objects the client can leave the channel. This model is preerd in satellite networks and wireless networks. A receiver is required to obtain a Session Description in some format before joining a ALC session. Examples of information that the Session Description should contain is stated in the list below. - Sender IP address. - Number of channels in the session and address and port number for each channel. - TSI for the session. - The multiple congestion control building block for the session.

B.1.2

RFC 3926 FLUTE - File Delivery over Unidirectional Transport

The FLUTE protocol version 1 is dened in RFC 3926 [23]. The ALC protocol only denes how to deliver arbitrary binary objects, FLUTE extends this by dening the abitrary objects as les. FLUTE is intended to deliver both large and small les to many receivers. It enables signaling and mapping of le properties so that the receivers can assign the properties to the received ALC objects. It adds the following four specications to ALC, the list is copied from the specication [23]:

B.1 File Delivery over Unidirectional Transport FLUTE

91

Dening of a le delivery session built on top of ALC, including transport details and timing constraints. In-band signaling of the transport parameters of the ALC session. In-band signaling of the properties of delivered les. Details associated with the multiplexing of multiple les within a session. Two of the most central parts of FLUTE are the File Delivery Session and the File Delivery Table. The ALC/LCT session is now called File Delivery Session and the object notation of ALC is in FLUTE referring to a le or a File Delivery Table instance. File Delivery Table FDT The FDT is a set of le descriptor entries that describes the les that are delivered in a File Delivery Session using attributes and parameters. The FDT is of XML structure and can be found in RFC 3926 [23]. Examples of such attributes are: - TOI. - FEC Information. - Size of transport object carrying the le. - URI of the actual le. - MIME type. - Size of le. - MD5 check-sum [15], to verify data integrity. Each descriptor entry must contain the Transport Object ID (TOI) and the URI. Since the TOI is included in every ALC/LCT data packet, this allows the receiver to determine which ALC/LCT data packet that belongs to which le. To each File Delivery Session there must be a FDT with le description entries to all les transmitted during that session. Received les that are not declared in the FDT are not considered to belong to that session. The FDT is delivered during the File Delivery Session as FDT instances which can contain one or more le description entries, and at most the entire FDT. The FDT instance may appear in any part of the le delivery session and data packets of the FDT instance can be interleaved with other data packets from the session. The specication recommends that the FDT instances are sent more often or with more FEC protection than the le(s) it describes, since it is needed to revover the le. It it also recommended that the FDT instance is sent before the le or les it describes. Within a File Delivery Session data from all objects, even the FDT instances can be multiplexed in any order.

92

File delivery protocol

To join a File Delivery Session, transport information is needed to set up the reception at the client side, same as described in the ALC session. Receival of these parameters and interpretation is not within the scope of FLUTE. The LCT header contains an FDT Instance ID, an identier of a le delivery table. This is used in the client to keep track of the received FDTs.

Upphovsrtt
Detta dokument hlls tillgngligt p Internet eller dess framtida ersttare under 25 r frn publiceringsdatum under frutsttning att inga extraordinra omstndigheter uppstr. Tillgng till dokumentet innebr tillstnd fr var och en att lsa, ladda ner, skriva ut enstaka kopior fr enskilt bruk och att anvnda det ofrndrat fr ickekommersiell forskning och fr undervisning. verfring av upphovsrtten vid en senare tidpunkt kan inte upphva detta tillstnd. All annan anvndning av dokumentet krver upphovsmannens medgivande. Fr att garantera ktheten, skerheten och tillgngligheten nns det lsningar av teknisk och administrativ art. Upphovsmannens ideella rtt innefattar rtt att bli nmnd som upphovsman i den omfattning som god sed krver vid anvndning av dokumentet p ovan beskrivna stt samt skydd mot att dokumentet ndras eller presenteras i sdan form eller i sdant sammanhang som r krnkande fr upphovsmannens litterra eller konstnrliga anseende eller egenart. Fr ytterligare information om Linkping University Electronic Press se frlagets hemsida http://www.ep.liu.se/

Copyright
The publishers will keep this document online on the Internet or its possible replacement for a period of 25 years from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linkping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/ c Karl-Johan Lundkvist