C. Lim and B.-D.

Lee: Development of a GINGA-NCL Receiver for Brazilian Mobile Broadcasting Services

1535

Development of a GINGA-NCL Receiver for Brazilian Mobile Broadcasting Services

Changhyeon Lim and Byoung-Dai Lee, Member, IEEE
Abstract GINGA-Nested Context Language (GINGANCL) is a subsystem of GINGA, the standard for the Brazilian mobile broadcasting service, and it specifies the mechanisms and services used to enable various interactive data services. The integral part of GINGA-NCL is the NCL declarative language that provides non-invasive control of a multimedia presentation in time and space, as well as user interaction. In particular, one of its core competitive advantages over other existing technologies, such as Broadcast Markup Language (BML) and Open Mobile Alliance-Rich Media Environment (OMA-RME), is that it is substantially light-weight. Therefore, in this paper, we introduce an implementation of a GINGANCL receiver for mobile handsets. The proposed solution supports full feature GINGA-NCL sets, including XHTML and ECMAScript1. Index Terms GINGA, GINGA-NCL, Interactive Data Services, Mobile Broadcast TV Service.

I. INTRODUCTION In addition to conventional A/V content, provisioning of interactive data services have been recognized as a new source of revenue for mobile broadcasting services. Interactive data services provide access to additional information in alignment with a TV program or enables users to be actively involved in a TV show through online voting (see Fig. 1.). As a result, several competing technologies are now coming to market and present new options for service providers to consider. Examples of enabling technologies adopted by todays mobile broadcast standards include BML for the Japanese 1-seg [5],

(a)

(b)

Fig. 1. Examples of interactive data services (excerpted from [10]): (a) EPG service and (b) SMS voting service. Changhyeon Lim is with the Software Platform R&D Group, DMC Division, Samsung Electronics, Co., Ltd., Suwon, Korea (email: changhyeon.lim@samsung.com). Byoung-Dai Lee is with the Department of Computer Science, Kyonggi University, Suwon, Korea (e-mail: blee@kgu.ac.kr). Contributed Paper Manuscript received 10/11/11 Current version published 12/27/11 Electronic version published 12/27/11.
1

OMA-RME for North Americas Advanced Television Standard Committee-Mobile/Handheld (ATSC-MH) [17], and GINGA-NCL for the Brazilian 1-seg [19], to name a few. BML is an XML-based standard and it allows text to be displayed on a 1-seg TV screen. The text contains information such as news, sports, and weather forecasts. One limitation of BML is that the presentation of the content and interactions with users rely entirely on implementations of individual devices that consume data in BML, as BML only delivers content that is to be rendered on a mobile device. In contrast, both OMA-RME and GINGA-NCL support rich media services and provide mechanisms to control multimedia presentations and interactions. Therefore, no matter which type of device a user has, the same content will be rendered and controlled in the same way. OMA-RME is based on 3rd Generation Partnership Project Dynamic and Interactive Multimedia Scenes (3GPP DIMS) [1] and MPEG-4 part 10 Lightweight Application Scene Representation (LASeR) [8] to present media objects as well as interactivity, ranging from user interactivity to client-server interactivity. Although this technology is able to provide a real-time rich media experience similar to what users get from a PC, significant efforts is required to implement. For instance, several subsystems, such as Scalable Vector Graphics (SVG) [3] processing, the ECMAScript engine, and the LASeR engine must be ported on the target terminals. Another interactive data service option provided by ATSC-MH is to utilize the XML-based <InteracivityFragment> element specified in the OMA-Broadcast Service Guide (OMA-BCAST SG) [16]. It provides mechanisms and relevant data structures to serve simple interactive services, such as SMS voting and web link. This approach is similar to BML in that only the content to be rendered is delivered within the <InteractivityFragment> element. In contrast with the aforementioned standards, GINGA, the standard for the Brazilian mobile broadcasting services, supports both a declarative approach and a procedural approach to provide a wide variety of interactive data services. For this purpose, GINGA specifies two subsystems. GINGANCL is a subsystem of GINGA that processes NCL documents, which define the spatial and temporal layout of media objects in a declarative manner. On the other hand, GINGA-J [20] provides the execution environment in which Java Xlet objects can run. While a data service based on GINGA-J is more flexible in that complex application logic can be implemented, in practice, a service based on GINGANCL is preferable due to its light-weight components, its

0098 3063/11/$20.00 2011 IEEE

1536

IEEE Transactions on Consumer Electronics, Vol. 57, No. 4, November 2011

reuse facility, and the multi-device support it offers. Therefore, this paper introduces an implementation of the GINGA-NCL receiver for mobile handsets in full support of GINGA-NCL features, including XHTML and ECMAScript. This paper is organized as follows. Section II introduces competing technologies for enabling interactive data services, while Section III presents a technical overview of GINGANCL. Section IV provides an in-depth explanation of the implementation of our proposed solution and Section V shows examples of the implementation results. Finally, Section VI presents the conclusions. II. RELATED WORK Several competing technologies have been introduced to enable mobile interactive TV services. BML is an XML-based standard developed by the Japanese Association of Radio Industries and Businesses (ARIB) as a data broadcasting specification for digital TV broadcasting. It specifies data coding and transmission systems to allow text to be displayed on a 1-seg TV screen. BML consists of XHTML, CSS-1 and CSS-2, ECMAScript, and extensions for broadcasting, i.e., Events, Objects, and Lists. Typically, a BML browser is primarily composed of a document process system and a script process system. The document process system generates DOM objects based on the results of BML document parsing and manages the CSS2 properties that control the display style. The script process system executes scripts that are part of a BML document [5]. BML is a typical approach used to combine generic XHTML and ECMAScript. According to [15], this approach, which is used to integrate XHTML and ECMAScript for variable manipulation, is very intrusive. For example, the ECMAScript code can be embedded in XHTML documents, or even more intrusively, inside attributes of XHTML elements. The limitation of this approach is that it is too flexible, thus making it difficult to decouple code and to distribute development work among different programming teams. Moreover, ECMAScript can access and modify the XHTML DOM tree under the total control of the programmer, which may cause unpredictable defects. Some examples of systems that are based on BML include [9][11][18]. OMA-RME content consists of OMA-RME scenes of visual objects, such as video, images, animation and text, and audio objects that are composed together to give the user a richer experience. Scene description language is based on the SVG Tiny 1.2 specification [3] and it is used to define visual and audio objects and the layout of these objects on the drawing canvas, and any temporal relationship between the objects in the scene, as well as local and remote interaction with scene objects. Scene commands accomplish changes to an OMA-RME scene and can be synchronized to the time line of the scene, based on XML language. The update commands are used to modify an OMA-RME scene. This part is similar to the live editing commands in GINGA-NCL. The update

commands allow insert, delete, replace and add operations on the OMA-RME scene ([1][8]). State management capabilities are provided through the save/restore/clean commands, which operate on the DOM attributes. A branch of the DOM tree can be activated or deactivated by the activation commands. Scripts can access the OMA-RME scene, including the ability to modify the DOM. These scripts cannot be loaded in the DOM. For locally stored data, the RME client can perform relative seek backward and forward in the RME timeline. Scene commands can be provided through the <sceneCommandGroup> element, which wraps a set of scene commands. OMA-RME also supports scripting functionality, specified by the ECMAScript Mobile Profile. Scripts are supplied with the initial scene or in scene updates, and are loaded into the DOM of the scene. They must be executed according to the rules as defined by SVG script processing. [6] presents a prototype implementation based on OMA-RME. GINGA-NCLs reuse facilities are more versatile than OMA-RMEs in that OMA-RME does not define the mechanism for saving, restoring and sharing the multimedia presentation state as a whole [13]. For instance, a viewer may change a TV channel and wish to return automatically to the TV channel that she was watching to avoid having to watch the advertisements. GINGA-NCL provides this mechanism in the declarative handling of local and global variables and by managing the presentation state [15]. III. TECHNICAL OVERVIEW OF BRAZILIAN 1-SEG AND GINGA_NCL This section presents a technical overview of the Brazilian 1-seg standard and GINGA-NCL. The Brazilian 1-seg is an extension to the Integrated Services Digital BroadcastingTerrestrial (ISDB-T) standard, which is typically known as Japanese 1-seg [4]. Both standards specify the same RF channel to deliver current terrestrial DTV services and mobile DTV services. ISDB-T divides each channel into 13 segments with a further segment separating it from the next channel. An HDTV broadcast signal occupies 12 segments and the remaining 13th segment is used for mobile receivers. Over the 1-seg, each multimedia component of a program is signaled by the program map table (PMT) being defined by MPEG-2 Transport Stream (TS): video, audio, service guide, data service session (DSM-CC), etc. The PMT is the complete collection of all program definitions for a transport stream. Basically, both 1-seg standards share the same foundation for transporting digital TV streams and multiplexing. However, differences exist between the multimedia player and the middleware. The summary of differences between the Japanese 1-seg and the Brazilian 1-seg are shown in Table I. Overall, the Brazilian 1-seg standard adopts more recent technologies in audio/video decoders and data services while retaining backward compatibility to the Japanese 1-seg in all areas except for data services. Additionally, data services in the Japanese 1-seg are enabled by BML technology, while the Brazilian 1-seg employs GINGA-NCL.

C. Lim and B.-D. Lee: Development of a GINGA-NCL Receiver for Brazilian Mobile Broadcasting Services TABLE I COMPARISON BETWEEN JAPANESE AND BRAZILIAN MOBILE DTV STANDARD Japan Video Decoder Video Format Frame Rate Audio Decoder Closed Caption Data Service Data Transport H.264 AVC Baseline Level 1.2 QVGA 320x240 / 320x180 15fps MPEG-2 AAC SBR only ARIB Standard BML DSM-CC Data Carousel Brazil H.264 AVC Baseline Level 1.3 QVGA 320x240 / 320x180 CIF 352x288 SQVGA 160x120 / 160x90 5/10/12/15/24/30 fps MPEG-4 HE AAC Level 2 SBR + PS ISO/IEC 8859-15 (Latin Extension) GINGA-NCL DSM-CC Object Carousel head body N/A id TABLE II STRUCTURE MODULE USED IN THE DTV PROFILE Element Attribute Content

1537

importedDocumentBase, ruleBase, transitionBase, regionBase, descriptorBase, connectorBase, meta, metadata port | property | media | context | switch | link | meta | metadata

GINGA is the middleware specified for the International Standard for Digital Television-Terrestrial (ISDTV-T) and consists of three primary components: GINGA-J, GINGANCL, and GINGA-core. The applications to be executed over GINGA are classified into two categories depending on the way they are written. Procedural applications are written using the Java language and are known as GINGA-J. Declarative applications are written using the NCL language and are known as GINGA-NCL. GIGNA-core is the component that offers a common core for the decoding and presentation of common types of content, such as PNG, JPEG, MPEG and other formats. GINGA-J and GINGA-NCL are built over the GINGA-core. GINGA-J has been developed for a universal Digital TV receiver used in terrestrial, cable, satellite and IPTV. However, GINGA-NCL is considered to be a lightweight solution compared to GINGA-J, so it is suitable for mobile digital TV receiver. The three main components of GINGA-NCL are Nested Context Language (NCL), Lua script, and DSM-CC [7]. NCL and Lua script (called as NCLua) format the presentation in a timeline. NCL defines the glue that holds together any type of the media objects in a multimedia presentation that are structured and that are related in time and space. Detailed descriptions on NCL elements are introduced by [14]. Below are some of important features worthy of noting. A NCL document consists of two basic elements: <head> and <body>. As seen in Table II, the <head> and <body> elements can have children. The <head> element specifies the reuse of the existing NCL documents using the <importNCL> element, the reuse of the spatio-temporal information of a single media object and the relationship between two media objects using the <compositeBase>, <ruleBase>, <transitionBase>, <regionBase>, and <connectorBase> elements. The <body> element is treated as a context object, having the same children as the <context> element. The <body> and <context> elements are composites that contain a set of nodes

and a set of links. The <media> element defines a media object specifying its type and its content location. The type attribute of this element can indicate a simple image and a video clip as well as an external imperative object (e.g. the Lua script) and external declarative language (e.g. the XHTML documents). Some special types are predefined by the language For example, application/x-ncl-settings type specifies an object whose properties are global variables. Four additional types are defined as follows: application/x-nclNCL, application/x-ncl-NCLua, application/x-gingaNCLet, and application/x-ncl-time. These types can be applied to a special <media> element whose content is a NCL document, a Lua script, an Xlet procedural code content, and universal time content (UTC), respectively. The <switch> element allows the definition of alternative document nodes to be chosen during the presentation time. The test rules used to select the switch component that is to be presented are defined by <rule> or <compositeRule> elements, which are defined as a child of the <head> element. The <link> element represents a relationship interconnecting the different nodes. A <link> element refers to a <causalConnector> and defines a set of binds, which associates each link endpoint to a role of the used connector. The Lua script, which is one of the imperative objects, is specified by the <media> element. The NCL provides a set of functions to start, stop, pause or resume in the NCL for the execution of Lua media objects. The results of these functions can be used in conditions, evaluated by the NCL formatter, to trigger actions on other NCL objects in the same document. In addition to commanding event state transitions, a procedural Lua code can also register itself as a listener of state transitions for any NCL event [13]. The DSM-CC for the GINGA-NCL should support the object carousel enabling it to carry directories ([2][7]). The object carousel is built on top of the data carousel, allowing the carousel to contain a set of directories and files, such as a PC file system. The object carousel specification is platformindependent and compatible with the Object Request Broker (ORB) framework as defined by CORBA. The data and attribute of a single object within an object carousel are transmitted in a single message in the form of a Broadcast Inter ORB Protocol (BIOP) message. BIOP messages are broadcast in a single module of a DSM-CC Data Carousel [7]. The message types can be carried in an object carousel as follows: 1) File messages represent real files that contain the actual data that comprises the file; 2) Directory messages represent logical containers for a set of file messages; 3)

1538

IEEE Transactions on Consumer Electronics, Vol. 57, No. 4, November 2011

DTV Application

NCL Formatter Renderer Private Base Manager

Layout manager HTML / Image / Text Renderer

Private Base

Event listener/ handler

Lua Engine

Middleware For EPG

AV Player

Payload Parser

NCL DOM Tree Generator Data Communication Interface

NCL Render Tree Generator

Event Communication Interface

DSM- CC Handler
Event Injection Interface Data Exchange Interface

DSM- CC Interpreter Object / Data Carousel

TS Demux

DSM- CC Parser

Fig. 2. System architecture of a GINGA-NCL receiver. The GINGA-NCL browser consists of the following three components: the DSM-CC Handler, the Private Base Manager, and the NCL Formatter.

Stream messages are references to MPEG-2 streams containing video or audio data; 4) Stream event messages describe a set of synchronization points; and 5) Service Gateway messages identify the root directory of the object carousel. IV. IMPLEMENTATION AND RESULTS This section provides an in-depth description of the receiver solution that we developed. A. Prototype Implementation This prototype consists of three modules: DSM-CC Handler, Private Base Manager (PBM), and NCL Formatter. The DSM-CC Handler is in charge of receiving the object carousel and delivering the data and the event to the PBM. The PBM is responsible for receiving live editing commands as well as maintaining the active NCL documents being presented. The NCL Formatter is the module that receives a NCL document and controls its presentation. The relationship among these three modules is shown in Fig. 2. At the lowest level of the DSM-CC Handler is the DSM Parser. It extracts the DownloadServerInitiate (DSI) DownloadInfoIndication (DII)/DownloadDataBlock (DDB) and constructs an object/data carousel and the directory/file structure. The DSM-CC Interpreter receives the results from the DSM Parser and constructs a NCL document that contains the interpretation. The DSM-CC Handler has separate interfaces with the PBM. The Event Injection Interface

triggers events to the PBM. The NCL live editing commands are delivered over the events. Other events can include such things as notifications of the progress status related to receiving the datagram and notifications of an update. The Data Exchange Interface writes the results from the DSM Parser to the file system and signals the PBM when a NCL document has arrived in the file system. The PBM is responsible for keeping track of the context of the GINGA browser. It maintains the state of the NCL documents and sends and receives active document events to facilitate live communication with the DSM-CC Handler. The NCL documents in a private base may be started, paused, resumed, and stopped. The XML-based live editing commands are divided into three subsets. The first subset activates and deactivates the private base. The second subset adds the NCL documents to a private base. Then, the NCL documents can be started, paused, resumed, and stopped. The third subset defines the commands for live editing, allowing the NCL elements to be added and removed, and allowing values to be set for the NCL <attribute> elements [13][14]. The NCL Formatter maintains the presentation variables by keeping track of its states. It interacts with the Lua engine and controls and keeps track of the script variables that will be a part of the document formatting. The NCL Formatter is also in charge of receiving a NCL document and controlling its presentation. The formatter deals with the NCL documents that are collected inside a data structure called a private base. It also supports the type of XHTML

C. Lim and B.-D. Lee: Development of a GINGA-NCL Receiver for Brazilian Mobile Broadcasting Services

1539

(a)

(b)

(c)

(c)

Fig. 3. Snapshots of the GINGA-NCL receiver: (a) video playback, (b) presentation of the NCL content, (c) presentation of the NCL document linked to the NCL content presented in (b), and (d) video playback after channel switching (Audiovisual materials 2011 Creative Common License).

media by communicating with the generic web core. The internal modules of the NCL Formatter act as follows: the DOM Generator stores the data on the DOM tree. The NCL Renderer then displays the NCL elements on the screen. The Layout Manager is in charge of the initial calculation required to position the NCL elements on the canvas of the screen. The role of the event handling module is to dispatch events and to handle user events. The Lua engine is responsible for procedural support of the NCL ecosystem. It handles all Lua script interpretations associated with the NCL content. The Lua engine also maintains the script context that is relevant to the active NCL document. The presentation of a NCL document requires the synchronization control of several media objects specified through the <media> element. For each media object, a media player can be loaded to control the object and its NCL events. The media player is the native media playing application that is designed to suite the media protocols. Media may be any native media available as per the W3C specification. The DTV Application is the component that displays the live video. It initializes and controls the overall middleware.

B. Implementation Results Fig. 3 shows the snapshots of the GINGA-NCL receiver running the prototype implementation. For this experiment, we used pre-recorded MPEG-2 transport streams. When the DTV Application is launched, it tunes to the frequency delivering the last TV channel that was watched, or it starts to scan all frequencies in case there is no cached data for the scanned frequencies. The DTV Application then analyzes the PMT to identify the elementary streams that deliver the audio and video content. Finally, it launches the media player to play back a TV program (see Fig. 3(a)). Once this is completed, the EPG middleware further analyzes the PMT to identify the additional data streams delivered over the frequency. In particular, if there is a DSM-CC session containing a NCL document, it commands the TS Demux module to receive the corresponding TS packets and to forward them to the DSM-CC Handler, which parses the object carousel and passes data and events to the PBM. The data stored in the PBM is finally manipulated by the NCL Formatter. Once a NCL document is completely received, the NCL Formatter presents the NCL document on the display. Fig. 3(b) shows the initial scene that allows a viewer to select possible options. For example, the icon labeled 1 allows a

1540

IEEE Transactions on Consumer Electronics, Vol. 57, No. 4, November 2011 [4] [5] [6] [7] [8] ARIB Standard STD-B31 V1.5, Transmission System for Digital Terrestrial Television Broadcasting, Association of Radio Industries and Businesses, July 2003. ARIB STD-B24 V5.2, Data Coding and Transmission Specification for Digital Broadcasting, Association of Radio Industries and Businesses, July 2005. C. Lim and B. Lee, Development of ATSC-MH Receiver for Mobile Digital TV Services, IEEE Transactions on Consumer Electronics, vol. 56, no. 3, pp. 1304-1310, 2010. ETSI TR 101 202 V1.2.1, Digital Video Broadcasting Implementation Guideline for Data Broadcasting, European Telecommunications Standard Institute, Jan. 2003. ISO/IEC 14496-20:2006(E), Information Technology Coding of Audio-Visual Objects Part 20: Lightweight Application Scene Representation (LASeR) and Simple Aggregation Format (SAF), International Standard Organization, June 2006. H. Segi, R. Takou, N. Seiyaman, and T. Takai, Development of a Prototype Data-Broadcasting Receiver with a High-Quality Voice Synthesizer, IEEE Transactions on Consumer Electronics, vol. 56, no. 1, pp. 169-174, 2010. J. Dufourd, O. Avaro, and C. Concolato, An MPEG Standard for Rich Media Services, IEEE Multimedia, vol. 12, no. 4, pp. 60-68, 2005. K. Hamada, et al., Prototype Mobile Phone Capable of Receiving and Collaborating with Terrestrial Digital TV Broadcasting, Proceedings of International Conference on Consumer Electronics, pp. 455-456, 2005. L. Soares, M. Moreno, and C. De Salles Soares Neto, Ginga-NCL: Declarative Middleware for Multimedia IPTV Services, IEEE Communications Magazine, pp. 74-81, 2010. L. Soares, R. Rodrigues, and M. Moreno, Ginga-ncl: The Declarative Environment of the Brazilian Digital TV System, Journal of the Brazilian Computer Society, vol. 12, pp. 37-46, 2007. L. Soares, R. Rodrigues, R. Costa, and M. Moreno, NCL Live Editing Commands, Technical Report No. 36/06, Departamento de Informtica, Dec. 2006, ISSN: 0103-9741. L. Soares, et al., Variable and State Handling in NCL, Multimedia Tools Applications, 50(3), pp. 465-489, Dec. 2010. OMA-AD-BCAST-V1_0-20081010-C, Mobile Broadcast Service Architecture, Open Mobile Alliance, Oct. 2008. OMA-TSRME-V1_0-20081014-C, Rich Media Environment, Candidate Version 1.0, Open Mobile Alliance, Oct. 2008. T. Kagiyama, S. Nabeshinia, and T. Shimoji, Method of Contents Cache Control in a BML/HTML Integrated Browser, Proceedings of 1st IEEE Conference on Consumer Communications and Networking, pp. 674-675, 2004. Volume 2 of ISDTV-T Standard 06, ISDTV-T Forum, Dec. 2006. Volume 4 of ISDTV-T Standard 06, ISDTV-T Forum, Dec. 2006.

viewer to play the current TV show in the full screen mode as shown in Fig. 3(a). When a viewer selects the icon labeled 2, the current NCL scene is replaced with the designated new NCL scene, as shown in Fig. 3(c). The new scene presents the EPG information. Through this linking mechanism, a NCL document enables the convergence of broadcast and mobile services. Finally, a viewer can switch to another channel using the icon labeled 3. We measured the performances of our prototype implementation during the trial services in Brazil (see Table III).
TABLE III MEASURED PERFORMANCE RELATED TO QOE Without Cache DTV Application Launch Time NCL Document Download Time Channel Switching Time 52.7 sec. 300 sec. 5.6 sec. With Cache 6.8 sec. 0.5 sec.

[9]

[10] [11] [12] [13] [14] [15] [16] [17] [18]

The trial service consisted of 18 channels, each of which is delivered over different frequencies. Therefore, the DTV application launch time in the no cached data case is significantly higher than that it is in the cached data case because the mobile handset must scan all of the available frequencies. The size of the NCL documents contained in the streams is approximately 300 KB and it takes about 300 seconds to download the documents. This time will naturally increase as the complexity and richness of the NCL documents increases. Hence, care must be given in designing data services for a mobile broadcasting environment. Finally, the channel zapping time is one of the most important QoE metrics for a mobile broadcasting service. In the current implementation, it takes about approximately 5.6 seconds to switch channels. H/W tuner operation is one of the primary components that directly determine the time it takes to switch channels. V. CONCLUSIONS The GINGA-NCL is an emerging standard for mobile DTV services in Brazil and its substantially declarative and lightweightness are core competitive advantages over other competing technologies, such as BML and OMA-RME. In this paper, we explore the internals of the GINGA-NCL standard, especially the GINGA-NCL tags and the DSM-CC object carousel, as they are essential to 1-seg service acquisition. Furthermore, based on the analysis, we developed a GINGA-NCL receiver for a mobile handset in full support of the GINGA-NCL specified in the standard. REFERENCES
[1] [2] 3GPP TS 26.142 V7.1.0, Dynamic Interactive Multimedia Scenes (DIMS), 3rd Generation Partnership Project, Oct. 2007. ABNT NBR 15606-1, Digital Terrestrial Television Data Coding and Transmission Specification for Digital Broadcasting, Part 1: Data Coding Specification, ABNT (Associacao Brasileira De Normas Tecnicas), Nov. 2007. A. Ola, et al., Scalable Vector Graphics (SVG) Tiny 1.2 Specification, World Wide Web Consortium, Aug. 2006.

[19] [20]

BIOGRAPHIES Changhyeon Lim received his B.S., M.S. and Ph.D. degrees in Electronic Engineering from Sogang University, Korea in 1998, 2000 and 2008, respectively. He has been a senior engineer of Samsung Electronics, Co., Ltd. in charge of development of mobile TV solutions from 2006. Recent areas of emphasis include IP multimedia system, mobile TV and vertical handover in fixed/mobile convergence environment. Byoung-Dai Lee (M00) is an assistant professor at the department of Kyonggi University, Korea. He received his B.S. and M.S. degrees in Computer Science from Yonsei University, Korea in 1996 and 1998 respectively. He received his Ph.D. degree in Computer Science and Engineering from University of Minnesota, twin cities, USA in 2003. Before joining the Kyonggi University, he worked at Samsung Electronics, Co., Ltd as a senior engineer from 2003 to 2010. During the period, he has participated in many commercialization projects related to mobile broadcast systems. His research interests include open mobile platform, mobile security and mobile multimedia broadcast. He is the corresponding author of this paper.

[3]