Software Platform for Mobile TV

Software Platform for Mobile TV M. Mohsin Saleemi 1,2, Jerker Björkqvist 1, Johan Lilius 1 1 Department of Information Technologies, 2 Turku Center for Computer Science, Åbo Akademi University, Finland, {muhammad.saleemi, jerker.bjorkqvist, johan.lilius}@abo.fi Abstract This paper investigates demands and constraints for the software platform of mobile TV, suggests possible solutions for them and proposes prototype software architecture for mobile TV based on this investigation and proposed solutions. The architecture is independent of specific broadcast technology. The paper also provides description of interactive applications that can be supported by Mobile TV. This research study is based on investigating existing software platforms including DVB-MHP, OCAP, ATSC-DASE, ACAP, ARIB- BML and MIDP, to expose their capabilities and limitations and identifies the enhancements to support interactive mobile TV applications. 1. Introduction In recent years, digitization of traditional systems has made significant and rapid progress in the sector of media consumption. The migration of traditional analog broadcast systems to digital systems has become the major part of global broadcasting. By using the Internet Protocol Datacasting (IPDC) technology, digital broadcast networks makes it possible to broadcast any kind of digital content to mobile handheld devices (Staffans, 2004). It enables convergence of TV and other multimedia content to mobile devices to offers a rich context of services including interactive, position-based and multimedia services. This broadcast and mobile convergence mobile TV- also imposes some limitations and contentions. To receive interactive broadcast services to wide range of devices having varying capabilities, there must be a common software platform that allows the convergence of cellular and broadcast networks and supports the execution of interactive software applications from different vendors. Without it, users will be unable to access and consume all of the available services to their handheld terminals. The software platform for interactive mobile TV applications is an evolving research area and has not yet been explored in detail. The ongoing research and development in this area can be seen in (instinct, 2004). In this paper, we point out the design requirements for mobile TV platform by investigating existing digital TV platforms and give the possible strategies for their solution. We also propose software architecture for mobile TV based on our research study. The rest of the paper is organized as follows: Section 2 describes common existing software standards and provides their precise comparison. Section 3 describes the different interactive applications to be supported by Mobile TV. Section 4 presents the design requirements and their proposed solutions for Mobile TV software platform. Section 5 gives the comparison of existing standards against our requirement study. In section 6 we present the proposed software architecture for Mobile TV. This section also represents description of interactive mobile applications that can be developed for Mobile TV. Finally, we describe future work and conclude the paper in Section 7. 2. Current Software Platform Solutions In this section we briefly described and analyzed common existing software platforms of digital TV and mobile phones, which are being used for the software application and service developments. 2.1 Multimedia Home Platform DVB-MHP is an open software platform that defines generic interface between interactive digital applications and user terminals on which these applications execute. In this way, applications from various service providers are interoperable with different MHP implementations independent of the underlying hardware, vendor and software. MHP specifies a way to deliver interactive applications within digital TV stream and describes how these applications are executed on the digital TV receiver. The application model and lifecycle management functionality in MHP is provided by JavaTV API. The MHP standard specifies software environment that must be offered by the receiver in order to compatible with MHP. DVB produced the GEM (Globally Executable MHP) specification which is a cut-down version of MHP that removes any dependencies on other DVB technologies. 2.2 OpenCable Application Platform OCAP is software platform for data broadcasting defined by CableLabs and is largely based on MHP with cable specific extensions. OCAP specifies the

application model and signalling information for broadcast applications. It extends MHP by supporting additional monitor application to give network operator a lot more control over the receiver. OCAP also provides support for applications which can run at any time and are not related to the currently watched TV channel. Example includes video-on-demand (VoD) application. 2.3 DTV Application Software Environment ATSC-DASE is the middleware platform based on ATSC (Advanced Television Systems Committee) digital broadcast standard. It provides the core functionalities required in digital TV including application model, life cycle signalling, data storage, service management. (Lee et al., 2002) describes the systems architecture and software environment for DASE systems. 2.4 Advanced common Application Platform ACAP is new standard that is designed by integrating OCAP and ATSC-DASE. The goal of ACAP is to define a common application framework between Cable and terrestrial digital TV. It combines Java part from OCAP and HTML part from DASE. It uses the ATSC service information for handling broadcast services. ACAP includes elements from full MHP specification and GEM, including GEM application signalling. 2.5 Broadcast Mark-up Language (BML) Platform BML is a XML based multimedia coding scheme defined by ARIB STD-B24 standard. It provides multimedia data broadcasting to enable viewers to access multimedia content and to get detailed information about the TV programs. Like other digital TV middleware standards, BML standard is also based on GEM to provide application model and life cycle management functionalities. The main difference of BML to the other standards is its transport protocol to carry applications and data. It uses DSM-CC data-carousel based transport protocol instead of object carousel. 2.6 Mobile Information Device Profile The Mobile Information Device Profile (MIDP) is designed for mobile phones and entry-level PDAs. It offers core application functionality required by mobile applications including user interface, network connectivity, data storage and application management. MIDP provides a complete environment for creating applications for handheld devices while having minimum usage of memory and power consumption. The key feature of highlevel MIDP applications is their portability across various cell phones by handling issues such as screen layout and button mapping. MIDP solution is based on connection limited device configuration (CLDC) which relies on K virtual machine, a derivative of JVM for resource constrained mobile devices. Comparison The table represents the main elements that are included in above mentioned platforms to give a precise comparison. Table 1: Comparison MHP OCAP/ACAP/ DASE BML MIDP Underlying JavaTV/GEM Java- GEM-based GEM-based Platform based Based Specification Receiver and transmission Receiver Receiver Receiver GUI AWT & HAVi AWT & HAVi AWT & HAVi LCDUI Application model DVB-J DVB-J/ACAP-J ECMA-Script MIDlet Service JSR 272 JavaTV API JavaTV API JavaTV API Selection API Service JSR 272 DVB-SI API JavaTV- SI API JavaTV- SI API information API Interactivity Signalling & Data Access Monitor application Unbounded applications DSM-CC Object carousel DSM-CC Object carousel DSM-CC Data carousel No Yes No No No Yes Yes Yes Limited Not specified The interactive digital TV standards MHP, OCAP, DASE, ACAP and BML were designed for Set-top boxes and integrated digital TV and provide application and service management functionalities. The user interface provided by these solutions are based on Abstract windows toolkit (AWT) and HAVi Specification that allow extensive windows management support such as window overlapping and resizing. Media presentation and control is provides by Java Media Framework (JMF). They provide support for return channel for interactivity and include service selection APIs to access list of services. These standards provide persistent data storage management as a part of receivers file system and give support to access broadcast data and MPEG-2 streams via DSM-CC protocols. They provide security and resource management functionalities to solve conflicts between applications and to offer fine-grain access control. MHP differs to these standards in the fact that each application in MHP is tied to one or more services whereas OCAP, ACAP, DASE, BML can have unbounded applications running simultaneously. MIDP is designed for limited configuration devices and its GUI APIs are contained in LCDUI package and are not based on AWT (Pawlan, 2001). The event handling mechanism in AWT and LCDUI are different as AWT event objects are dynamically created when user interacts whereas LCDUI events are method calls that pass the event parameters. This is because of the fact that processing of dynamically created objects requires more memory

and power requirements that is not realistic for handheld devices. MIDP provide features such as application life cycle management, dynamically loaded application handling, resource and data storage management and end-to-end security model for applications. It provides broadcast application and service management functionality using Mobile Broadcast Service API for Handheld Terminals (JSR 272). Currently, MIDP does not support broadcast protocols. 3. Interactivity in Mobile TV Due to the limited hardware and software resources, it is more likely that the people will use interactive services like voting, chatting, shopping, breaking news and games and interactivity related to TV programs etc rather than watching movies on their mobile phones. In this section we present description of three specific interactive applications that have diverse nature are likely to be supported by Mobile TV. 1. The first interactive application is Who wants to be Millionaire? This application contains streaming and graphics objects to be displayed on screen. This application would be in the form of precompiled java programs that require execution environment in the receivers to execute application. The viewers can take part to the game live from their homes by answering the same questions as the TV contestant using their remote controls. The real time behaviour of the application provides synchronization to the broadcast and ensures that the answers were not displayed to the viewers before the TV contestant answered the same question. The points of the viewers are accumulated and they can get application updates through return channel. The viewer with the highest points is then invited to the TV program. 2. We are implementing a multiplayer locationbased interactive mobile game Abot using DVB- H broadcast channel combined with a point-to-point channel, such as 3G or GPRS. The interactivity in such a service is dependent on the user s actions where the action of one user affects the internal status of the server providing the service, allowing all other users to experience the changes. We defined three categories of interaction in this system. Instantaneous pull-type interaction is sporadic communication which is followed by a near-instantaneous response and typically consumes very little bandwidth. Predicted push-type of interaction covers the case where the location history or some other user action sequence reveals to the system the most probable near-future communication need of the user. The server should be able to push data to the terminal before the user actually requests it. The collective push-type interaction is related to multicast data which reflects the current state of the service. 3. ESG is the interactive application that provides extensive program information and support for a variety of interactive TV services. Users can interact with ESG to purchase and download multimedia content associated with the broadcast. 4. Design Requirements and Proposed Solutions for Mobile TV Software Platform Based on the usability studies and end-user scenarios of interactive applications described in the last section, we identify the design requirements for the software platform of Mobile TV. These requirements and their possible solutions are presented in this section to draw a sketch for the development of platform supporting interactive services. R1. Capability to support IPDC IPDC is a set of specifications that defines Electronic Service Guide (ESG), service access management, delivery protocols, signaling and QoS aspects to deliver any kind of content to mobile handheld terminals using internet protocol (IP). We propose that the architecture should contain a software component to manage IPDC access and handle network interfaces for the reception of broadcast services and applications. This component would hide underlying functionalities of networks making it possible to receive and consume IPDC services from any kind of network. R2. Simple user interface One solution, to cope with variety of handheld terminals having varying capabilities, is to create different versions of application for each family of devices according to its capabilities. This is not a feasible solution as creating separate versions for each would mean to create several thousands of applications, which is not realizable. The alternative solution is to use higher abstraction which would hide the device specific functionalities making it possible for same services and applications to be able to adapt to specific user interface of the target device. We propose to build a common user interface framework which can be based on XML for describing the graphical layouts. This framework would have advantage of handling the differing user interface implementations and applications would be unaware of the user interface used (Honkala et al, 2004; Luyten & Coninx, 2001) R3. Support for low screen resolution In order to make digital TV services compelling on low resolution screens, the encoding technique must be efficient and flexible enough to support

lower bandwidth requirement for mobile environment. MPEG-4/H.264 is a much more flexible compression standard than MPEG-2 as it improves quality, has more error robustness and uses video frames of Quarter Common Intermediate Format (QCIF). The resolutions that need to be supported by the platform include for example 480*320, 320*320, and lower. R4. Support for run dynamically loaded applications For dynamically loaded applications the platform must have a software component for the management of these applications. This component is responsible for reception of applications, storing them into the local memory of terminal and makes them ready for execution. This component will handle complete life cycle of applications. R5. Management of interactive broadcast services and applications Broadcast services and applications can be managed by providing a software component in the platform that supports all the functionalities to administer and utilize the broadcast content and services. The main tasks of this component are to search the services that are currently available to the user, selection of service user want to access, check if the user is authorized to use that service, perform the subscription of the service if necessary, download the data that is necessary to run the applications and retrieve and consume the contents such as TV programs, audio and video etc. R6. Hardware / software resources and power consumption The general recommendation is to have the effective power saving modes to handle resource and power management. The response times need to be short even in the sleeping mode of the terminal. Reactions to the user inputs, signalling of broadcast service have to be immediate. R7. Return Channel The return channel for interactive applications and services can be provided by cellular communication networks such as 3G or GPRS. R8. Streaming Protocols For streaming services, audio/video streaming protocols should be included in the protocol stack. RTP can be used for delivering audio video streams. It is used with RTCP to monitor the QoS and to convey information about ongoing session. R9. Support for positioning techniques The Positioning techniques can be used in mobile TV context to enable the operators to deliver the location-based services to a specific geographical area based on user s current position. GPS and cell- ID techniques could be used. R10. Transparent switching between cellular and TV applications The software platform must provide some mechanism for some type of transparent switching between cellular and TV applications. There can be optionally implemented some technique that can record the live stream when the user is busy to attend the call, and when the call is finished, the program restart from the point where viewer stopped watching. R11. Format of ESG information The bandwidth required for broadcast TV contents is very expensive and processing power of the handheld terminals is low. These factors impose some limitations to the format of ESG metadata which should use simple and lightweight representation. XML based data representation would be the best option for several reasons. First, XML is best suited for describing the structured information like metadata. Second, XML is an appropriate format which is already using in existing deployed systems e.g. TV Anytime. Third, it would be easy to update the information in ESG by using XML and it can be easily converted to other formats like HTML. R12. Delivery of ESG and contents The ESG can be delivered to the terminals as one big entity or several small entities by using any of the two transmission channels: broadcast or interactive. The same protocols, ALC and FLUTE, which are used to deliver the files, can be used to deliver ESG data. In that case the ESG is partitioned into number of small packages and these packages are delivered in a FLUTE session as transport object and the delivery information can be carried in File Delivery Table (FDT). Each package has a distinct ID and by using the header information, the terminal will be capable of identifying which part of the ESG is transmitted. Service guide updates can be retrieved via the interaction channel. For delivery of ESG through interaction channel, HTTP would be used to send request for the service guide. The response of this HTTP request will contain ESG data. 5. Comparison of Existing Software Solutions Against our Requirement Study The table 1 gives concise comparison between the software platform solutions described in section 2. Table 2: Comparison against Mobile TV Requirements Requirement Analysis of Mobile MHP/ ACAP/ TV Software Platform OCAP DASE BML MIDP Support for IPDC No No No No Broadcast Protocols Yes Yes Yes No Service and app. management Yes Yes Yes Yes Service discovery and selection Yes Yes Yes Yes Support for low screen resolution No No No Yes Support for simpler user interface Not Not Not Application directly directly directly dependent Required resources More More More Fewer Support for DRM Yes Yes Yes Yes Return channel Yes Yes Yes Yes Dynamically loaded applications Yes Yes Yes Yes

This comparison is made with respect to the requirement analysis identified in last section. All of these standards provide support for mobile reception of services, although, except MIDP all were originally designed for fixed receivers. MIDP provide support for low screen resolution and simple GUI as it is developed for mobile phones. It provides service and application management functionalities using the new API Mobile Broadcast Service API for Handheld Terminals. All other standards are based on JavaTV and GEM which provide application life cycle model and service management functionalities. 6 Prototype Software Architecture of Mobile TV In this section, we propose prototype software architecture for mobile TV based on our requirement analysis and solutions. This architecture specifies all central components from the hardware level to application level, which are necessary to support digital TV and other multimedia and interactive services in mobile handheld terminals. the hardware components that are necessary for providing both functionalities i.e. cellular services and broadcast services. The hardware API provides the layer of abstraction for hardware from different manufacturers. The next higher level is the protocol stack. This protocol stack contains all the protocols that are necessary for the system to receive the digital broadcast. There are different candidate protocols that can be used e.g. ALC and FLUTE for file and ESG delivery, RTP and RTCP for A/V streaming. Parallel to these hardware and protocol stack layer is the real time operating system. For java-based applications, the Java Virtual Machine provides a dynamic platform with a secure execution environment. For the other applications like C/C++ based, the system has native libraries to execute these applications. The next higher level is middleware layer which is the core component of the software platform of mobile TV. Using different separate modules, all the functionalities related to mobile TV are implemented in this part. The IPDC module handles all the operations related to the reception and signalling of the IPDC services and applications. The ESG engine signals the receiver to tune into selected IPDC service and receives the input ESG data. The decoding of the audio and video streams is handled by the audio/video decoder software solutions. Digital right management is provided for content protection. 7. Conclusions This paper investigates the existing software platform solutions to explore their capabilities and limitations to support interactive mobile TV. Based on this research study, we identify the demands and constraints for the software structure of mobile TV, suggest possible solutions for them and propose prototype software architecture for mobile TV. As future work we plan to consider the implementation detail of this architecture and to evaluate a specific interactive mobile TV application scenario to give the proof of concept. Fig. 1: Mobile TV Architecture Figure 1 shows the overall architecture of mobile TV. In this architecture, we focused on the TV related elements of the mobile handheld terminal. The elements required for the phone functions such as phone specific software stacks, APIs, protocol stacks etc. are not shown in the figure but they, of course, are present in the system. The lowest level of this architecture, the hardware layer contains all References 1. Homepage of the Instinct project. http://www.ist-instinct.org. 2004 2. Honkala. M, Cesar P. & Vuorimaa P. (2004). A device independent XML user agent for multimedia terminals. IEEE (ISMSE 04) 3. Luyten K. & Coninx K. (2001). Systems: Design, Specification, and Verification: 8th International Workshop, DSV-IS 2001. 4. Staffans L. (2004). Internet protocol datacasting, a technology overview. Master s thesis, Helsinki University of Technology, Finland, March 2004. 5. Pawlan M. (2001). Introduction to digital TV applications programming. February 2001. 6. Kwangkee Lee, Jungho Lee and Hyogun Lee (2002). A Middleware architecture for ITV receivers, Consumer Electronics, 2002.