Interactive Broadcast Services for Mobile Phones. Uwe Rauschenbach 1, Stephan Skrodzki 2

Transcription

1 Interactive Broadcast Services for Mobile Phones Uwe Rauschenbach 1, Stephan Skrodzki 2 1 Siemens AG, Corporate Technology, Munich, Germany, uwe.rauschenbach@siemens.com 2 GMIT, Berlin, Germany, skrodzki@gmit-gmbh.de Abstract. This contribution discusses some recent developments in the field of broadcasting to mobile phones. Starting with a description of use cases and business models as a foundation, this paper gives an overview of the status of bearer technologies and related standardisation activities. After that, the MiTV system is presented, which supports appealing interactive mobile TV services. 1 Introduction In recent times, broadcasting technologies which provide content directly to mobile phones have generated a lot of interest. The important aspect of using a mobile phone as a terminal is that it already offers a two-way return channel, allowing truly interactive broadcast services. This fact is a main advantage compared to traditional television, where a return channel is still the exception. Furthermore, content can be offered on the move to users outside the classical television prime times. Last but not least, by combining the wealth of television content with the billing experience of cellular network operators, flexible billing models for the consumed content become possible. 2 The User and Business Perspective 2.1 Use Cases A mobile broadcast service is an attractive product from the end user perspective. The value of TV services is known from TV consumption at home and does not have to be explained to the users. Mobile broadcasting technologies enable a set of interesting use cases: Passive mobile TV. This use case assumes that classic TV channels are resolution-reduced and re-broadcasted using mobile broadcast technology. The formats will not support any interaction. It is envisioned that the first services to appear will fall into this category. Interactive mobile TV. This use case adds interactivity options (e.g., vote, retrieve additional information, call in) to passive mobile TV. As it is more challenging w.r.t. terminal support, this will be probably the next step in deployment after passive mobile TV. Buffered personalised infotainment: In carousel mode, different pieces of content formatted into files or clips are repeatedly broadcasted. The terminal device stores this broadcast (or parts of it based on some user preferences) for later off-line consumption. 2.2 Business Models To make mobile broadcast services a reality, several different business models are possible. Each business model requires that several roles are taken by the involved players. The content provider provides the content to be broadcasted. This content may then be edited and bundled by the content aggregator, considering the special requirements of the mobile environment. The service provider is the entity who offers the complete service to the customer. This includes the actual media content, additional components like interactive applications and the Electronic Service Guide (see below). Also, the service provider is the contractual partner of the customer who receives the revenues for the service and distributes them to the other players. As mobile broadcast networks are a complex infrastructure and may be shared by multiple service providers, there are also the roles of broadcast network operator (who operates the mobile broadcast network) and mobile network operator (who operates the cellular network). The following business models are possible: Broadcaster-centric business model. Here, a broadcaster offers mobile broadcast services to his users. He owns the customer relationship and usually also the broadcast network. Also, broadcasters normally have access to own or licensed content. To do the billing, he may team up with a mobile network operator, or he may do this himself in the same way today s pay TV subscriptions work. Mobile Network Operator (MNO) centric business model. In this business model, the MNO offers mobile broadcast services to his traditional customer base and performs the billing. He may also operate the mobile broadcast network, or he may rent capacity from a broadcast network operator. Furthermore, he has to make

2 contracts with content providers to obtain attractive content for the service. Hybrid Business Model. Frequency spectrum is a scarce resource in many countries. To cope with this, a hybrid business model is required which allows sharing of this resource. Here, an operator company runs the broadcast network and performs the role of the content aggregator. Several content providers (e.g. TV Stations) provide their content to the content aggregator who re-encodes the content to be suitable to be transmitted over the mobile broadcast network. The operator company acts as a kind of wholesaler, providing the mobile broadcast service to a number of mobile network operators who re-sell access to the service to their customers. To allow differentiation of the different MNOs, this model requires means of branding the service on one hand and the possibility to enrich the service with mobile network operator specific, exclusive content on the other hand. Figure 1: A DVB-H terminal prototype 3 Broadcast Bearer Technologies Several mobile broadcast technologies have been developed in the last few years. This section gives a brief summary, before one particular technology DVB-H is discussed in greater detail. 3.1 Technology Landscape Mobile broadcast technologies have evolved out of different roots. Based on the standards for digital television (DVB - Digital Video Broadcast) [1] and digital radio (DAB - Digital Audio Broadcast), the mobile broadcast technologies DVB-H (H for Handheld) [2] and DMB (Digital Multimedia Broadcast) [3] have been developed. While DVB-H is a European standard based on DVB using IP as transport layer, a Korean consortium has developed DMB based on DAB, relying on MPEG-2 transport streams [6]. The IP layer gives DVB-H an advantage over DMB for convergent services, using the service layer standards which will be described in the next section. However, there are activities in progress to add an IP layer to DMB as well. Based on cellular network technology, MBMS (Multimedia Broadcast Multicast Services) [4] provide a transmission channel in cellular networks which can address multiple or all devices in a cell at once. In Northern America, a similar system called BCMCS (BroadCast MultiCast Service) is being standardised. Furthermore, Qualcomm s MediaFLO [5] technology may play a certain role in the future, especially in the United States. This technology has been designed from scratch with mobile TV as the main application, optimised for short channel switching times. 3.2 A Closer Look at DVB-H DVB-H has been developed by the DVB Project [1] as an extension of their terrestrial broadcasting standard DVB- T. The modifications to DVB-T aim at making the technology suitable for mobile reception by terminals with limited battery resources. DVB-H transmits all data based on IP this traffic is encapsulated into the MPEG- 2 transport stream [6] by the multi protocol encapsulation method (MPE) as defined by DVB. The following features have been added to DVB-T: Time slicing: One big challenge in mobile reception of DVB signals is the power consumption of the receiver circuits. Since classic DVB has been designed for stationary set top boxes, power consumption has not been an issue yet. DVB-H solves the problem by introducing a time slicing mode. Figure 2 illustrates the idea. Usually, a DVB-H service consumes a bit rate of 200 to 500 kbps (playback bit rate bp in Figure 2), whereas the capacity of a typical DVB-H channel is several Mbps (transmission bit rate bx in Figure 2). Instead of transmitting multiple services in parallel as currently done in DVB, the IP encapsulator which generates the DVB-H transport streams collects the IP traffic of each service in a buffer and sends the buffered data at once in short bursts using the full bit rate of the channel (time slicing). Referring to Figure 2, the following equation applies: b p t p = b x t x. In the data packets of each burst, the time until the next burst starts is signalled. The receiver circuits have only to be switched on during the time periods of the bursts of the currently selected service. This way, battery power is saved. Error protection: In mobile environments, interference and fading cause interruptions of the reception. In order to ensure a continuous service, DVB-H uses forward error correction (FEC) to protect the MPE data packets. For each MPE packet, redundancy is added in the form of a Reed-Solomon code. If some of the bytes of such an error protected packet are erroneous, the redundant data can be used to recover them. Modulation: DVB-H defines an additional set of modulation parameters (the so-called 4k mode). This mode better supports mobile reception at higher speeds

3 than the modes defined by DVB-T which have been optimised for stationary reception. BCAST re-uses the codecs defined by DVB IPDC, MBMS and BCMCS, depending on which underlying transmission system is used by the actual service. Xfer b x Play b p bitrate Play time t p of burst One service n 1 Xfer time t x of burst Possible receiver OFF time time Transport Protocols for Streams and Files This function group defines which protocols are used for realtime services (streaming) and non-realtime services (file download). In both DVB IPDC and OMA BCAST, RTP [7] is used for streaming and FLUTE [8] is used for multicast file download. In contrast to file download in bi-directional networks, multicast file download uses a carousel mode to repeatedly push files to the clients. stream of IP packets buffer send burst burst of IP packets Figure 2: DVB-H time slicing principle 4 Service Layer Standardisation DVB-H, DMB and MBMS provide the bearer technologies for Mobile TV. However, in order to deliver a full service to the users in an interoperable way, service layer components are required on top of the bearers. These components have recently been developed. Both DVB [1] and the Open Mobile Alliance (OMA) [9] have developed or are developing service layer specifications. DVB has recently approved phase 1 of the IP Datacast over DVB-H standard [2] specifying how to deliver mobile broadcast services over the DVB-H bearer. The OMA is developing the BCAST Enabler specification, which defines how to deliver these services using three different bearers: DVB-H, MBMS and BCMCS. Both specifications address the following main functional groups: Audio and Video Codecs Transport Protocols Electronic Service Guide Service and Content Protection Standard Video Audio DVB IPDC MBMS BCMCS H.264 (recommended), VC-1 (optional) H.264 (mandatory), H.263 (optional) HE AAC v2 (mandatory), AMR WB+ (optional) HE AAC v2 (recommended), AMR WB+ (recommended) Under consideration, goal: harmonized with MBMS Table 1:A/V Codecs in Mobile TV Systems Audio and Video Codecs Most mobile TV systems are relying on H.264 and HE AAC v2, allowing optionally other codecs. OMA Electronic Service Guide (ESG) The ESG is the entry point via which the user reaches the service. Especially if the hybrid business model is used, one important requirement is that the ESG is flexible enough to allow differentiation. The Service Guide lists the available services and describes how a user can purchase access to them if they are not free to air. Furthermore, additional information can be provided to the audience: service previews, schedules and metadata about individual pieces of content. Invisible to the user, also all technical data which allow a terminal to select and render the services are provided as part of the ESG. ESG data are coded using XML, and each standard defines its own way to packetise and compress ESG data. FLUTE is used to transmit the ESG data containers to the terminals. Furthermore, management information is transmitted which allows for different update rates of different parts of the ESG and for an efficient detection of those parts of the ESG which have been updated Service and Content Protection This function group can be split into two subgroups: service protection which encrypts and protects the data while being transmitted (i.e. protection is removed once the terminal receives the service) and content protection which protects content during its whole lifecycle (i.e. protection is kept also when the content is inside the terminal and is only removed in some trusted agent which is part of the terminal). For content protection, the common understanding in OMA BCAST and DVB IPDC is to use OMA DRM 2.0 [10]. Service protection determines who is allowed to access the service and which player in the value chain controls the access. To support the multiple different business models, the service layer standards have introduced different profiles.

4 The common idea of all profiles is to separate media encryption from key management. Media encryption is the lowest layer, it provides the foundation which the different key management systems can be built upon. The task of the key management systems is to provide the decryption keys for the encrypted media to the terminals of the authorized users. Key Management Stream Encryption LTK Media Deliver LTK Encrypt STK STK 1..STK n using LTK Encrypt Media using STK Service System OMA DRM2 / Smartcard, other Short Term Key Message Encrypted Media Receive LTK LTK Decrypt STKs using LTK STK 1..STK n Decrypt Media Media using STK Terminal Figure 3: Principle of Service Protection Key management systems are usually exploiting hierarchies of keys with different frequency of changes in order to provide improved security against brute force attacks. Figure 3 illustrates the idea. To encrypt/decrypt the media layer, a so-called short term key (STK) is used which changes every few seconds. The sequence of short term keys is encrypted with long term keys (LTK), and sent along with the encrypted content to all users alike. LTKs are valid for a longer time, e.g., a show / movie or a time period ranging from a number of hours to a number of days. At the receiver side, LTKs are used to decrypt the STKs which then in turn are used to decrypt the media. This way, LTKs provide access to the service and are consequently the item which a user has to purchase in order to get access to paid services. LTKs are delivered to individual users in a trusted channel, e.g., encrypted with a shared secret that may be stored, e.g., in the SIM card of the user. This system allows different business models: in pay per view mode, each long term key secures access to one atomic piece of content and must be paid separately. Subscription is realized by billing the request to get access to a service for a certain time. Then, during that time, LTKs are delivered without triggering a new billing. Pay per time can be implemented by LTKs with a short validity (e.g. an hour) and billing each such key. The two service layer standards OMA BCAST and DVB IPDC share very similar media encryption layers, using IPSec, SRTP and ISMACryp. They use different methods to deliver the keys to the user, however. Figure 4 provides a comparison. DVB IPDC has two key management profiles: The 18Crypt profile standardizes a key hierarchy like the one just described and uses the mechanisms provided by OMA DRM 2.0 to deliver the LTKs to the terminals. The competing Open Framework profile is aligned with the mechanisms used in today s stationary pay TV systems. Basically, only an interface is defined into which different vertical solutions can be plugged the key management details are not specified. Even though, the basic principle of a key hierarchy is also used. OMA BCAST also defines two profiles; however, both are fully specified. The DRM profile is very similar to the 18Crypt profile of DVB IPDC. The Smartcard profile reuses the service protection functionality provided by the 3G cellular standards MBMS and BCMCS. It exploits the GBA_U protocol for key exchange between the network and the smartcard, establishing a shared secret called the Subscriber Management Key (SMK) which is assigned with an individual user. The MIKEY protocol is used to deliver Long Term Key Messages (LTKM) and Short Term Key Messages (STKM). 18Crypt OMA DRM 2.0 Rights object SEK/PEK KSM Vendor specific solutions IPSec, SRTP, ISMACryp DVB IPDC Open Framework DRM Profile OMA DRM 2.0 Rights object SEK/PEK STKM GBA_U SMK GBA_U / MIKEY LTKM MIKEY STKM IPSec, SRTP, ISMACryp 1.1 OMA BCAST Figure 4: Service Protection Profiles Further functions Smartcard profile OMA BCAST additionally defines the functions to send Notifications to the users and specifies support for basic use cases of browser-based Interactive Services. To support full interactivity, an interaction middleware must be specified which allows to run a broadcasted interactive TV application on any terminal. A Java Specification Request (JSR-272) [11] is currently under way to define such a middleware for interactive applications. Upon this middleware, an interaction browser application can run, such as a LASeR player [12] or the MiTV browser which is described in the following section.

5 5 Adding Interaction to Mobile Broadcast Services This section describes a prototypical framework for mobile interactive TV applications, named as MiTV. The MiTV framework allows enriching a mobile TV program with additional interactive content. This additional content may be synchronised with the time line of the mobile TV video stream if this is required. Synchronisation accuracy is in the areas of fractions of seconds. In order to support this, a framework has been defined which separates the screen into different rectangular areas, the so called ifields. The layout of the screen is defined for both landscape and portrait mode displays. Figure 5: The MiTV Client Application Each ifield has an output behaviour and an input behaviour. The output behaviour assigns a bitmap and/or text label to be displayed along with the definition of backand foreground colours as well as font name and size. The input behaviour defines how the area reacts when it is activated by means of a pen or softkey. For this purpose, a URI is assigned. A number of special URIs are defined for e.g. sending SMS, spawning an external Web Browser or switching the application to a new internal state. The dynamic behaviour of an ifield is controlled by NTP time stamps which are related to the time stamps of the video. This allows synchronising the output and input behaviour with the time line of the video service. All content which is shown in the MiTV client application is transported in its most suitable way of granularity, to allow low bit rate and fast update rates along with a very robust handling of dropouts caused by reception faults. The content objects are called MiTV objects. Figure 5 shows an example. 5.1 Transport Protocol As described in section 4.1.2, there are already basic protocol definitions for transporting data. The MiTV framework uses the FLUTE protocol to transport the MiTV objects. Due to the highly synchronised character of the content, the IP stream which contains the FLUTE carousel should reside in the same time slice as the video stream. As MiTV objects tend to be small and of high number, they may be combined into containers for efficient use of FLUTE. Containers may be compressed to achieve higher transmission rates. To meet the representation principles described in the next section, it is sufficient to transport in a carousel only the objects of the current scene representation along with the objects scheduled to show up in a reasonable future (e.g. around seconds). To tie objects semantically together (like three answers to a quiz question), they should be transported in the same container, which ensures that either all objects or none of them are received. 5.2 Representation Principles A MiTV Object does only have a start time. To delete the content of an ifield, the object with the youngest start time has to be replaced by an empty object. With this assumption it is very easy to calculate a current scene representation. A scene is defined as the combination of all objects which are older than the current time, restricted by the condition that if two objects of the same ifield ID and state are in this set, only the youngest is kept. This arrangement is called the "youngest old principle. MiTV Authoring MiTV Server FLUTE IPE Video Streamer or Live Encoder Content provider / Broadcaster 5.3 MiTV Data Flow Transmitter Video Player FLUTE DVB-H Figure 6: The MiTV Data Flow MiTV Client Terminal GSM Figure 6 gives a rough architecture of the MiTV data flow. As already stated, MiTV tries to use as much of the existing standards as possible. As a result, the framework can reuse existing applications on server and client side: FLUTE, video streamer and player, return channel applications for sending SMS or showing HTML content.

6 5.4 The MiTV Server The basic task of the MiTV server is to play out a preproduced archive of MiTV objects at the right time to be synchronized with the video stream. To achieve this, the MiTV server controls also the video streamer thus providing a complete playout solution. In addition to the playback of material pre-produced with an authoring tool, the MiTV server is able to generate MiTV objects from live content such as RSS feeds, HTML pages or play lists. Those modules of the MiTV server are called MiTV aggregators. Their spectrum reaches from generic functionality like mentioned above up to highly customized aggregators for special applications, where customers could set votes or bets over SMS triggered by a MiTV application. Figure 7: The MiTV 123TV application 5.5 Integration with Upcoming Standards Until today there are missing areas in the field of standardisation for mobile itv applications. For this reason, the current version of the MiTV client is a native binary application, implemented using C++. However, the object format and the transport protocol have been designed to be used on top of the upcoming JAVA APIs for mobile itv. Picture 6 shows the layering of a JAVA based MiTV client on the JSRs 272 and 248. Figure 8: MiTV in the Mobile TV Protocol Stack This means, that after the port to these APIs, a MiTV client will be completely platform independent and using the same server and transport technology as the native client, giving the highest possibility of easy migration to the content and service owners. 6 Conclusion In the future, mobile terminals will play a growing role in receiving TV services, using mobile broadcast technology. Various use cases centred on TV content are possible and have generated a lot of interest recently. Mobile broadcast technology has the potential to change the current business models in the mobile communications world. MNOs will have to team up with content providers and broadcasters to make attractive services a reality. The convergence of broadcast and cellular networks is the key enabler and driver for this development. References [1] DVB Homepage. [2] DVB-H website. [3] Seung Kyu Lee, Cheon Sup Kwak: Video for Mobile and Handheld Devices: Design and Implementation of the Korean T-DMB System. Proc. IBC 2004 conference, Sept. 9-13, 2004, Amsterdam, The Netherlands, pp. 391 ff. [4] F. Mademann: 3GPP MBMS Bearer Service. Proc. Multiradio Multimedia Communications 2005, January 2005, Berlin, Germany. [5] QUALCOMM MediaFLO Homepage. [6] Information Technology - Generic Coding of Moving Pictures and Associated Audio: Systems. ITU Recommendation H.222.0, ISO/IEC [7] RFC RTP: A Transport Protocol for Real-Time Applications. [8] RFC FLUTE: File Delivery over Unidirectional Transport. [9] OpenMobileAlliance / Browser and Content / Mobile Broadcast standardization activity. /wg_committees/bac.html [10] OMA Digital Rights Management V2.0 Approved Enabler. com/release_program/drm_v2_0.html [11] Java Specification Request JSR 272: Mobile Broadcast Service API for Handheld Terminals. Java Community Process website. detail?id=272 [12] Information technology - Coding of audio-visual objects - Part 20: MPEG LASeR (Lightweight Applications Scene Representation), ISO/IEC