Investigation and implementation of the OMA BCAST Service Interaction Function

(1)

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

Investigation and implementation of the OMA

BCAST Service Interaction Function

Examensarbete utfört i Datatransmission vid Tekniska högskolan i Linköping

av

Karl-Johan Lundkvist

LiTH-ISY-EX--07/3979--SE

Linköping 2007

Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

(2)

(3)

Investigation and implementation of the OMA

BCAST Service Interaction Function

Examensarbete utfört i Datatransmission

vid Tekniska högskolan i Linköping

av

Karl-Johan Lundkvist

LiTH-ISY-EX--07/3979--SE

Handledare: Iftikhar Waheed

Ericsson AB

Examinator: Danyo Danev

isy, Linköpings universitet

(4)

(5)

Avdelning, Institution Division, Department

Division of Telecommunications Department of Electrical Engineering Linköpings universitet S-581 83 Linköping, Sweden Datum Date 2007-05-22 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport

URL för elektronisk version http://www.ep.liu.se

ISBN — ISRN

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

ISSN —

Titel Title

Undersökning och implementation av OMA BCAST Service Interaction Function Investigation and implementation of the OMA BCAST Service Interaction Func-tion Författare Author Karl-Johan Lundkvist Sammanfattning Abstract

This thesis is a study of a new specification for end user interactivity developed by the Open Mobile Alliance, the specification is called OMA BCAST Service Interaction Function. The specification 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 specification 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

(6)

(7)

Abstract

This thesis is a study of a new specification for end user interactivity developed by the Open Mobile Alliance, the specification is called OMA BCAST Service Interaction Function. The specification 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 specification is still of draft version and the scope of this thesis has been to investigate the Service Interaction Function and implement a PC prototype.

(8)

(9)

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.

(10)

(11)

(12)

Abbreviations

Abbreviation Explanation

AAC Advanced Audio Coding

ALC Asynchronous Layered Coding

API Application Programming Interface

ASM Any-Source Multicast

ATSC Advanced Television Systems Committee

BML Broadcast Markup Language

COFDM Coded Orthogonal Frequency-Division Multiplexing

CSS Cascading Style Sheet

DiBEG Digital Broadcasting Experts Group

DVB-H Digital Video Broadcasting - Handheld

DVB-T Digital Video Broadcasting - Terrestrial DTTB Digital Terrestrial Television Broadcast

EPG Electronic Program Guide

ESG Electronic Service Guide

FEC Forward Error Correction

FDT File Delivery Table

FLUTE File Delivery over Unidirectional Transport

GERAN GSM EDGE Radio Access Network

GZIP GNU ZIP

HDTV High definition Television

IETF The Internet Engineering Task Force

IMD Interactivity Media Document

IPDC IP Datacast

IPSec IP Security

IPTV Internet Protocol Television

ISDB Integrated Services Digital Broadcasting

ITU International Telecommunication Union

LDTV Low Definition Television

MBMS Mobile Broadcast/Multicast Service

MMS Multimedia Messaging Service

OFDM Orthogonal Frequency Division Multiplexing

OMA Open Mobile Alliance

OMA BCAST OMA – Broadcast, a working group within OMA that examine the need of ”Mobile Broadcast Services”

QAM Quadrature Amplitude Modulation

QPSK Quadrature Phase-Shift Keying

SDTV Standard Definition Television

SMS Short Message Service

SSM Source-Specific Multicast

STB Set-Top Box

SVG Scalar Vector Grapics

UDP User Datagram Protocol

(13)

xi Abbreviation Explanation

UMTS Universal Mobile Telecommunications System

UTRAN UMTS Terrestrial Radio Access Network

VHF Very High Frequency

VOD Video On Demand

VSB Vestigial Side Band

WAP Wireless Application Protocol

(14)

(15)

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 ser-vices are IP based, IP datacasting. IP datacasting technologies are used to deliver television and other IP based services in both terrestrial broadcasting and broad-casted 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 tele-vision 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

(20)

devices; ASTC1 _{[1], DVB–H}2 _{[5] and ISDB}3 _{[24]. In Europe DVB–H 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 hand-held devices. The most obvious difference 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 DVB–H 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 defining 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 de-scribes 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 trans-mission information. Other information is intended to be presented to the user on screen, like an Electronic Program Guide (EPG), that describes the different 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 specification. This is done in two steps.

1. Theoretical investigation and evaluation of the OMA BCAST Service Inter-action Function, discovery of flaws 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 specification.

The OMA BCAST Standard specifies a couple of different types of interac-tion between a client and server. The type of interacinterac-tion that lies within the scope of this thesis is called Service Interaction; interaction as a part of a

1_{Advanced Television Systems Committee, http://www.atsc.org/} 2_{Digital Video Broadcasting – Handheld, http://www.dvb-h.org/} 3_{Integrated Services Digital Broadcasting, http://www.dibeg.org/}

(21)

1.3 Problem description 3

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 iden-tified for the thesis.

1. Discovery of weaknesses and problems of the OMA BCAST Service Interac-tion FuncInterac-tion specificaInterac-tion.

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 inter-activity 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 specifies 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 inter-activity session.

In addition to the objectives given above, requirements where defined for the demo application, defined 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 specifications from OMA BCAST. The following workflow is expected.

1. Literature study of OMA BCAST, Mobile-TV/IPTV and IP datacast solu-tions.

2. Investigation of OMA BCAST Service Interaction Function.

3. System design of demo application.

4. Implementation

(22)

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 five main parts, Theoretical Background, Investigation, Implementation, Conclusions and Appendencies. The scope of each part is ex-plained below.

Part I: Theoretical Background

This first part of the thesis serves as an introduction to the world of digital tele-vision 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 different 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 offered 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 specifications 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 specification that enables interactivity in OMA BCAST.

(23)

1.6 Outline 5

This chapter discusses different problems and weaknessess with the OMA Service Interaction Function. A number of solutions to the dif-ferent 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 file delivery protocol called: File Delivery over Unidirectional Transport – FLUTE. An experimental protocol for broadcasting files over any IP-network.

(24)

(25)

Part I

Theoretical Background

(26)

(27)

Chapter 2

IP Datacasting

This chapter introduces different 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 com-bined with a bi-directional interactivity path. IP Datacasting thus enables re-ception 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 ap-plications supporting a format called Digital Video Broadcast – Terrestrial (DVB– T). In Sweden the public terrestrial analogue television net is in the process of clos-ing down and is beclos-ing replaced by DVB–T transmissions. DVB–T is usclos-ing 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]

(28)

Two of the other DTTB standardization bodies are the ATSC and ISDB. The Advanced Television Systems Committee (ATSC) has developed the digital televi-sion 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 chan-nel of 1920*1080 pixels resolution or six regular SDTV chanchan-nels. As transport stream the MPEG-2 specification is used and Dolby Digital AC-3 is used for audio coding. [1]

Integrated Services Digital Broadcasting (ISDB) is the format for broadcast-ing video and audio developed and used in Japan. ISDB is using Orthogo-nal 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 specification for end user interactivity. For DVB–T, one specification is called DVB–Return Channel Terrestrial (DVB–RCT). The DVB–RCT is a specification 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 defined specifications for interaction, but in this case the phys-ical layer and the data link layer are not defined. The specification instead de-fines 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 specifications from the Open Mobile Alliance is dis-cussed 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 (DVB–H) [5], was developed from DVB–T to support handheld receivers, such as mobile phones. The biggest difference 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 DVB–H 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

(29)

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 re-ception 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 QUAL-COMM and is used on the North American market. It is an end-to-end solution that enables video/audio multicasting, IP datacasting and In-teracitive services etc. [42].

• WorldDMB (World Digital Multimedia Broadcasting)

The WorldDMB, the forum that also developed Digital Audio Broad-casting (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 proto-col, another word could also be Broadband Television – BTV. Television delivered

(30)

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 tech-nology” [7], a technology that offers voice, data and video.

A real definition 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 offer an end to end Quality of Service (QoS), different users or data flows have different priority and a certain level of performance to a specific data flow should be guaranteed [22]. It should not be mistaken for ”Internet Video Stream-ing” which is meant for personal computers via the Internet without quality guar-antee. IPTV requires a set-top box for rendering the video content.

The ITU-T1 is currently working on the standardization of IPTV. All com-mercial 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] offering 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

gam-ing 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.

(31)

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 DVB–H 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 infras-tructure 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 offer 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 op-erators 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 be-longing to the current TV-show. Many different 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.

(32)

Broadcaster led approach

Mobile television could be a service offered 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 me-dia industry and the content industry are created. A number of different 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 con-tent from different 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 offered by one single provider, the existing mobile telecom operator.

(33)

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 au-dio/video content via MBMS, described in Chapter 2.1.1, using the existing cellu-lar network.

2.4 Summary

This chapter has introduced digital television and IP Datacasting. At first, 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 briefly introduced.

(34)

(35)

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 offered ser-vices.

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 different 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

(36)

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 different video clips from a selection.

There are a lot of protocols and standards for the EPG, most of them propri-etary, being developed today. A sub working group of the OMA called BCAST is currently working on a definition of a mobile broadcast service enabler called OMA BCAST Service Enabler, which also contains a specification 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 televi-sion the framework of how to deliver and arrange service information or metadata, is often called Electronic Service Guide.

(37)

Chapter 4

Open Mobile Alliance

This chapter introduces the Open Mobile Alliance and presents their service en-abler for mobile handheld devices, OMA BCAST Service Enen-abler.

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, ge-ographies, service providers, operators, and networks, while allowing businesses to compete through innovation and differentiation. [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 offering 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 specifications for data services.

Existence of network technologies specified by outside parties is presumed and the specifications that are developed are transport agnostic, the specification is the same regardless of the underlying network.

BCAST is a sub-working group within the OMA that was created to define 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].

(38)

4.2 OMA BCAST Service Enabler

The OMA BCAST Service Enabler is a bearer agnostic application layer for broad-casted 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 defined with technologies like DVB–H, over regular IP broadcast networks, and 3GPP–MBMS for cellular networks. The receiving ter-minals are all different kinds of terter-minals, 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 Pay-ment, 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 stream-ing 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 real-ized 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 pro-tocol like RTP or RTSP will be used. When delivering files 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.

(39)

4.2 OMA BCAST Service Enabler 21

(40)

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 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 figure 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 prefferd 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 file 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.

(41)

Part II

Investigation

(42)

(43)

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 defined 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 inter-active television, TV-shows could be ordered on demand or a selection of different 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, re-ceive personalized advertisement related to the current TV–show 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 televi-sion, 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 interac-tivity in DVB–T or DVB for satellite transmission, DVB–S, 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 implementa-tion 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 DVB–RCT, 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

(44)

which limits the user experience and the interactivity provisioning is limited to the TV program providers.

IPTV provides a far more flexible 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 specifies four different 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 specified in the specification OMA Broadcast Services

Technical Specification [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 de-scribes 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 inter-active 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 con-tent 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 different 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

(45)

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 DVB–H 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 chan-nel as the service they are associated with, or over a different access chanchan-nel. Distribution over a different access channel is enabled by association of an Inter-activityData fragment to a Schedule fragment that is referred to by a different 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 offer 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 Interactivi-tyData fragments.

5.2.2 Interactivity Media Document – IMD

The IMD is an XML–document that describes the media objects that are related to a specific 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 different access channel. If a different access channel is used, this channel is accessed with the use of information in another Access frag-ment. The described content should also be retrivable over the interaction channel using the InteractivityMediaURL defined in the InteractivityData fragment.

The root element of the IMD, InteractivityMediaDocument, is of cardi-nality 0..N and contains six different attributes, groupID, groupPosition, id,

ver-sion, validFrom and validTo. The groupID is an ID of the group of IMDs, probably

(46)

specifying a relative position of the IMD in the group of IMDs. The id is globally unique and identifies the IMD, newer versions of IMDs overrides the old ones when they are received. validFrom and validTo specifies when the IMD is valid.

This InteractivityMedia XML-document has sub-elements called

MediaOb-jectGroups. The most important sub-elements to the MediaObjectGroup are

the MediaObjectSet, Figure 5.3, BackoffTimer, Figure 5.5 and the

Action-Descriptor, 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 ses-sion. A MediaObjectGroup could contain information about media objects that should be rendered at the beginning of the interactivity session, another

Me-diaObjectGroup 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 file, a compressed archive file of gzip [16] type, which can contain several media objects – like XHTML + picture. Alter-natively, it declares one single uncompressed media file. The actual data file, 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

Me-diaObjectSets 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 de-pending on the end user action. If the end user does not react before the time given in the attribute inputAllowedTime, the pointer of attribute

(47)

5.2 OMA Service Interaction Function 29

(48)

(49)

5.2 OMA Service Interaction Function 31

on the terminal. When the user undertakes action within the given time inter-val 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: BackoffTimer

A time window is specified 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 offsetTime. The time window is [offsetTime,

offset-Time + randomoffset-Time], 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 specification ”Mobile Broadcast Services” [37] presents a set of rules regarding the support of protocols in the terminals.

(50)

Figure 5.4. Element: ActionDescriptor

(51)

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

pro-tocol 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 offered to the user.

The specification also suggests how to arrange the MediaObjectSets depend-ing 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 file containing the MMS presentation part and all the different media ob-jects. Each bundled file should be declared in a Object element of the

MediaOb-jectSet. If the user chooses to participate in the session, the MMS template is

then filled in and sent back via the interaction channel, realized as MMS.

The instructions when using XHTML are similar. One gzip archive file con-taining all the media objects that should be rendered at a specific point in the session is declared in a MediaObjectSet. Every object in the archive file 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 defined. Figure 5.6 depicts this session.

A time-dependent behaviour of the session can be enabled by defining 3

Me-diaObjectGroups in the IMD. The first 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 defined by the OnActionPointer. If the user waits too long or does not provide any input the MediaObjectSet from the MediaObjectGroup defined by the

On-TimeOutPointer 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 define the next question in the voting session.

5.3 Network aspects

Three new, or modified, 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

(52)

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 identifies three different areas of synergy beween IP data-casting and IPTV in IPTV – a different television [7]:

• Complementary coverage

– Digital terrestrial broadcasting is often designed to cover huge

terri-tories. 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 ter-restrial broadcast is insufficient.

• Common sets of services

– The same services should be available over both broadband and

broad-cast, 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 set-top box or a home multimedia system and the OMA specifications are intended

(53)

5.3 Network aspects 35

for mobile phones and other handheld devices. The use of OMA specifications 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 tele-vision for digital teletele-vision. 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 defines middleware as a ”Layer of software that

pro-vides 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 Inter-face (API) used to let the user access interactive applications and services regard-less 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 different 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 au-dience, open standards were requested for the middleware running on the set top boxes. The open standards are developed by the same organizations that have cre-ated 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 Com-mon 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.

(54)

Multimedia Home Platform – MHP

The MHP is huge, with many different profiles 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 specific application programming interfaces (APIs).

• Content formats: images, video subtitles and downloadable fonts. • DVB-HTML: Support for web browsing.

• Network: Defines 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 specified subset of Java and XHTML defined 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 defined

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 defined profiles of MHP to create a smooth transit from the analogue television:

• Enhanced Broadcast – A profile for low cost receivers for accessing

broad-casted services and should provide the same functionality as the existing middleware systems.

(55)

5.4 Summary 37

• Interactive Broadcast – Same as the Enhanced Broadcast profile 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 defined a set of technologies to use for interactive television. The main difference 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 differences are the amount of transmission metadata and parameters. Since MHP is intended for fixed 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 different 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.

(56)

(57)

Chapter 6

Investigation of the OMA

BCAST Service Interaction

Function

This chapter discusses the different problems and issues that have arised during the work with the OMA BCAST Service Interaction Function, thus it fulfils point 1 of Chapter 1.3. This chapter also gives different solutions on how to realize two different delivery modes which fulfils point 4 of Chapter 1.3. Since the OMA BCAST specification 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 OMA BCAST Service Interaction Function

issues

6.1.1 IMD issues

The XML-schema of the IMD [36] and the entire chapter about the Service Func-tion 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 specifications 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 defined within one MediaObjectGroup, Fig-ure 5.2, the terminal needs to keep track of how to use the OnActionPointer.

(58)

To which of the media objects in the MediaObjectGroup should it apply? For example, one MediaObjectGroup could contain a number of XHTML-pages 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 specification. If only one media object can be rendered at the same time the complexity of interactive ses-sions 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 file, the Content-Type attribute should be: ”application/x-gzip”, see Figure 5.3. The terminal then needs to refer to the Object elements to figure out what kind of interactivity technology that is declared in the MediaObjectSet.

6. Inconsistency in the IMD. Attributes and elements have names like "Content-Location", "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 different 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 de-scribed by the OMA specification, see Chapter 5.2.4. If the interactive technology

Investigation and implementation of the OMA BCAST Service Interaction Function

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

Investigation and implementation of the OMA

BCAST Service Interaction Function

Investigation and implementation of the OMA

BCAST Service Interaction Function

Examensarbete utfört i Datatransmission

vid Tekniska högskolan i Linköping

av

Abstract

Acknowledgements

Abbreviations

Contents

I

Theoretical Background

7

II

Investigation

23

III

Implementation

51

IV

Conclusions

73

V

Appendices

83

Chapter 1

Introduction

1.1

Background

1.2

Purpose

1.3

Problem description

1.4

Method

1.5

Limitations

1.6

Outline

Part I

Theoretical Background

Chapter 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

Chapter 3

Metadata framework

3.1

Electronic Program Guide

3.2

Electronic Service Guide

3.3

Summary

Chapter 4

Open Mobile Alliance

4.1

Open Mobile Alliance – OMA

4.2

OMA BCAST Service Enabler

4.3

Summary

Part II

Investigation

Chapter 5

User Interactivity