You are on page 1of 9

Ginga-NCL: Declarative Middleware for

Multimedia IPTV Services


Luiz Fernando Gomes Soares, Marcio Ferreira Moreno, Carlos de Salles Soares Neto, and Marcelo
Ferreira Moreno, Pontifical Catholic University of Rio de Janeiro

©2010 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this
material for advertising or promotional purposes or for creating new collective works for resale or
redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must
be obtained from the IEEE. The original publication is available at
http://dx.doi.org/10.1109/MCOM.2010.5473867
GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 74

CONSUMER COMMUNICATIONS AND NETWORKING

Ginga-NCL: Declarative Middleware for


Multimedia IPTV Services
Luiz Fernando Gomes Soares, Marcio Ferreira Moreno, Carlos de Salles Soares Neto, and Marcelo Fer-
reira Moreno, Pontifical Catholic University of Rio de Janeiro

ABSTRACT designed for hypermedia document specification


for the web. The language’s flexibility, reuse
This article presents the innovative features facility, multidevice support, application content,
of Ginga-NCL, an open middleware specifica- presentation adaptability, and mainly its intrinsic
tion for multimedia IPTV services. Ginga-NCL ability to easily define spatiotemporal synchro-
relies on the Nested Context Language, a nization among media assets, including viewer
domain-specific declarative language targeting interactions, make it an outstanding solution for
multimedia application authoring. As a glue lan- all kinds of digital TV (DTV) systems, particu-
guage, NCL relates media objects in time and larly IPTV systems. For particular cases, for
space without restricting or imposing any media example, when dynamic content generation is
content type, including media objects with imper- needed, NCL provides Lua (imperative) script-
ative and declarative code written using other ing language [2] support.
languages. Other NCL features include support In 2007 NCL was adopted in the Brazilian
for multidevice presentations, content adapta- terrestrial DTV standard, SBTVD. In the begin-
tions, presentation adaptations, and advanced ning of 2009 NCL and its user agent, called
code reuse. Ginga-NCL allows NCL applications Ginga-NCL, became part of International Stan-
to be modified on the fly by means of live edit- dard for Digital Broadcasting (ISDB) standards
ing commands. Initially defined as the standard (the previously known Japanese standard now
middleware for the Brazilian terrestrial DTV increased with Brazilian improvements) and part
system, Ginga-NCL has recently become part of of International Telecommunication Union —
ISDB standards and an ITU-T Recommendation Radiocommunication Standardization Sector
for IPTV services. (ITU-R) Recommendation BT 1699. Also in
2009, NCL and Ginga-NCL became an ITU —
INTRODUCTION Telecommunication Standardization Sector
(ITU-T) Recommendation for IPTV services [3].
IPTV systems have brought the last triple-play NCL and Ginga-NCL were designed at the
service to IP networks. This digital convergence TeleMídia Laboratory at the Pontifical Catholic
should be supported not only at low-level net- University of Rio de Janeiro (PUC-Rio). The
work layers, but also at the application layer. work was coordinated by the authors of this arti-
Thus, an application programming language that cle, who also chaired ITU-T H.761 and the
is able to support, integrate, and coordinate a Brazilian DTV Middleware Working Group.
number of different media objects in a simple Independent of the distribution network where
and synchronized manner is a very important they may be applied, all Ginga-NCL and NCL
requirement in this new domain. The solution specifications are open and totally royalty-free.
can come from languages using the declarative A reference open source implementation of
paradigm. Ginga-NCL1 has been developed to easily inte-
Declarative languages emphasize the high- grate a variety of media-object players (for
level description of an application, rather than audio, video, image, text, etc.), including impera-
its decomposition into an algorithmic implemen- tive execution engines and other declarative pre-
tation, as is done when using imperative lan- sentation engines. As aforementioned, Lua code
guages. Such declarative descriptions are easier can be embedded in an NCL application by
1 Ginga-NCL reference to devise and understand than imperative ones, means of a special NCL object type called
implementation is avail- which usually require a programming expert. NCLua. Because of its simplicity, efficiency, and
able under the GPLv2 However, declarative languages typically target powerful data description syntax, Lua was con-
license at an application domain and define a specific sidered the natural scripting language for Ginga-
http://www.ncl.org.br model to design applications in this domain. NCL. The Lua engine 2 is small and written in
When an application design matches the declar- ANSI/C, making it easily portable to several
2 The Lua engine is also ative language model, the declarative paradigm hardware platforms. Lua is one of the most pop-
distributed as free soft- is generally the best choice. ular languages in the entertainment area.
ware under the MIT Nested Context Language (NCL) [1] is a This article presents some NCL features and
license. declarative XML-based language initially discusses how Ginga-NCL can be used in IPTV

74 0163-6804/10/$25.00 © 2010 IEEE IEEE Communications Magazine • June 2010


GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 75

systems. The article is organized as follows. The licensing, media presentation control, and
next section overviews some related work. We TCP/IP communications. LIME supports not A declarative
then introduce the main NCL concepts. We pre- only user interaction events, but also broadcaster
application is an
sent the Ginga-NCL architecture for IPTV sys- events, by means of bevent and beitem elements.
tems. The last section is dedicated to our final A beitem element describes an event message application whose
remarks. and the corresponding action (usually a function initial entity is of a
written in EcmaScript) to be accomplished when
the event occurs. Note that although spatiotem- declarative content
RELATED WORK poral synchronization among media objects can type. An imperative
DTV applications can be partitioned into a set be controlled by broadcast systems, the behavior
application is an
of declarative applications and a set of impera- must be imperatively defined using scripts.
tive applications [4]. A declarative application is After the advent of broadband TV, broadcast application whose
an application whose initial entity is of a declara- content may share its audience with downloaded initial entity is of
tive content type. An imperative application is widgets and online tasks like browsing and mes-
an application whose initial entity is of an imper- saging. This has pushed broadcasters and service an imperative
ative content type. operators to define standardized platforms that content type.
Most terrestrial DTV systems offer support harmonize and explore this hybrid scenario.
for both paradigms. For example, the European HbbTV [16] supports web technologies like
Digital Video Broadcast (DVB )[5] system and XHTML and EcmaScript for broadcast or down-
the American Advanced Television Systems loaded applications. However, application signal-
Committee (ATSC) [6] system support Java, ing is done in the broadcast domain. The HbbTV
EcmaScript, and XHTML in their middleware standardization process started in the third quar-
specifications; the Association of Radio Indus- ter of 2009 in the European Telecommunica-
tries and Businesses (ARIB) Japanese system tions Standards Institute (ETSI).
also provides both declarative and imperative The BBC’s Project Canvas [17] is an initiative
support, although current products implement to standardize a common platform that broad-
only the declarative language BML [7], with casters can join, making their multimedia con-
EcmaScript as the scripting language. The Brazil- tent available to compatible IPTV terminals.
ian SBTVD system specifies Java and Lua as Some discussions and consultations are still run-
imperative languages for its middleware, called ning at BBC Trust, and there are no technical
Ginga. NCL is the declarative language of Ginga. standards published yet, although web technolo-
Besides offering an application programming gies are said to be a natural choice.
interface (API) for interactive applications like Verizon’s FiOS TV [18] offers a framework
terrestrial DTV, an IPTV middleware integrates for developing TV widgets based on the Lua lan-
specific IPTV components and services. Among guage. The framework incorporates the Lua vir-
those components, the most common are video tual machine and extended Lua APIs such as
on demand (VoD), linear TV, IP communica- Graphics, Events, Timers, and Webservices.
tion, remote software update, and content search Authoring DTV applications using imperative
engines. languages is more complex and more error-
Most IPTV service providers use proprietary prone than using declarative domain-specific
middleware implementations [8] from vendors languages (DSLs). Moreover, imperative inter-
like Microsoft, Minerva, Orca, Siemens, Soft- preted system languages like Java have engines
AtHome, and Alcatel-Lucent. Microsoft Media- that are very resource consuming and have a
room (an evolution of Microsoft TV) [9] is based considerable memory footprint. On the other
on the .NET framework compact for end termi- hand, XHTML carries a legacy from previous
nals, in order to offer a C#/XML API (Sil- technologies developed for text navigation and
verlight) for applications. Minerva Networks has formatting, and lots of add-ons have been creat-
developed a middleware known as iTVManager ed to overcome its limitations. XHTML is
[10], which offers a C language interface for its focused on user interactions for media asset pre-
applications. The RIGHTV middleware [11], sentation synchronization, forcing application
developed by Orca Interactive, is based on authors to solve spatiotemporal synchronization
XHTML browsers. Siemens has acquired Myrio that goes further than simple user interactions,
[12], which offers Java and XHTML APIs. The as well as content and presentation adaptations
SoftAtHome operating platform [13] is a recent and other issues, using imperative objects, usual-
initiative from Orange, Thomson, and Sagem to ly implemented using EcmaScript. Thus, the
provide a declarative application environment great advantage of using declarative DSL is lost,
based on HTML, JavaScript, and Adobe Flash. with the expense of using a scripting language
Alcatel-Lucent’s MiViewTV [14] offers a devel- greedy in CPU and memory consumption.
opment framework totally based on Adobe A declarative approach that fulfills the main
Flash. requirements of a DTV application, relegating
Lightweight Interactive Multimedia Environ- to the imperative approach only particular com-
ment (LIME) [15], like NCL, is an ITU-T Rec- putations, seems to be the right solution for a
ommendation for IPTV multimedia applications DTV middleware API. This approach would
and is based on the Japanese BML standard for boost integration, simplicity and better resource
broadcasting. LIME specifies a small profile of usage in IPTV platforms. Besides that, it would
XHTML, CSS, DOM, and EcmaScript, where make the authoring process easier and less error-
broadcast-specific functions from BML were prone.
removed. The LIME EcmaScript API contains NCL [1] and MPEG-4 Lightweight Applica-
extensions to deal with IPTV-specific functional- tion Scene Representation (LASeR) [19] are the
ities such as IPTV EPG, persistency, content technologies currently closest to fulfilling these

IEEE Communications Magazine • June 2010 75


GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 76

requirements. Based on scalable vector graphics element, <ncl>, and its child elements, <head>
NCL defines the glue (SVG) [20] and other extensions [19], LASeR and <body>, following the terminology adopted
has its focus on media synchronization, as well by Word Wide Web Consortium (W3C) stan-
that holds media as NCL. Both languages support content and dards.
objects together in a presentation adaptability, and provide support The <head> element may have
multimedia for live editing commands. NCL reuse facilities <importedDocumentBase>, <ruleBase>,
[21] are more versatile than LASeR’s. NCL also <transitionBase>, <regionBase>,
presentation. offers more powerful support to applications tar- <descriptorBase>, and <connectorBase>
NCL applications geting multiple exhibition devices. Despite being elements as its children. The <body> element
a good solution, mainly for mobile devices,
only define how LASeR does not have a commercial implemen-
media objects are tation yet.
1: <ncl>
structured and NCL was the first standardized technology of 2: <head>
the ITU-T multimedia application framework 3: <importedDocumentBase>
related, in time and for IPTV services [3, 22]. Using NCL, an author 4: <importNCL/>
can declaratively describe the spatial and tempo- 5: </importedDocumentBase>
space. As a glue 6: <ruleBase>
ral behavior of a multimedia presentation, asso- 7: <importBase/>
language, NCL does ciate hyperlinks (for viewer interactions) with 8: <compositeRule/>
not restrict or media objects, define alternatives for content 9: <rule>
and content presentation (adaptation), and 10: </ruleBase>
prescribe any media- 11: <transitionBase>
describe the presentation layout on multiple 12: <importBase/>
object content type. exhibition devices. In addition, NCL provides an 13: <transition/>
API that allows building and modifying an appli- 14: </transitionBase>
cation on the fly through live editing commands. 15: <regionBase>
16: <importBase/>
NCL does not define any media itself. As a glue 17: <region>
language, NCL bypasses legacy problems embed- 18: <region/>
ding other objects. Moreover, NCL supports a 19: </region>
very efficient and lightweight scripting language 20: </regionBase>
21: <descreiptorBase>
when algorithmic computations are needed. 22: <importBase/>
23: <descriptor>
24: <descriptorParam/>
THE NESTED CONTEXT LANGUAGE 25: </descriptor>
26: <descriptorSwitch>
NCL defines the glue that holds media objects 27: <defaultDescriptor/>
together in a multimedia presentation. NCL 28: <bindRule/>
applications only define how media objects are 29: <descriptor/>
structured and related in time and space. As a 30: </descriptorSwitch>
31: </descriptorBase>
glue language, NCL does not restrict or pre- 32: <connectorBase>
scribe any media object content type. In this 33: <importBase/>
sense, media objects may be image objects 34: <causalConnector>
(JPEG, PNG, etc.), video objects (MPEG, MOV, 35: <connectorParam/>
36: <compoundCondition/>
etc.), audio objects (MP3, WMA, etc.), text 37: <compoundAction/>
objects (TXT, PDF, etc.), imperative objects 38: </causalConnector>
(Xlet, Lua, etc.), other declarative objects 39: </connectorBase>
(HTML, LIME, SVG, nested NCL, etc.), and so 40: </head>
41: <body>
on. Which media objects are supported depends 42: <port/>
on which media players are embedded in the 43: <property/>
NCL engine. It is worth mentioning that NCL 44: <media>
treats main audiovisual streams like all other 45: <area/>
46: <property/>
media objects it can relate. It should also be 47: </media>
stressed that NCL treats an XHTML document 48: <context>
as one of its possible media object types. There- 49: <port/>
fore, NCL does not substitute but embeds 50: <property/>
51: <media/>
XHTML-based documents. 52: <context/>
In the recently approved revision of ITU-R 53: <link/>
Recommendation BT.1699 [23], NCL was intro- 54: <switch/>
duced as a glue language to harmonize declara- 55: </context>
56: <switch>
tive content for DTV. NCL can be viewed as a 57: <defaultComponent/>
feasible solution to promote lightweight integra- 58: <switchPort/>
tion among most multimedia application tech- 59: <bindRule/>
nologies mentioned in the previous section. 60: <media/>
61: <context/>
NCL is an XML application that follows the 62: <switch/>
modularization approach. Several NCL profiles 63: <link>
have been defined. Of special interest is the 64: <linkParam/>
Enhanced DTV (EDTV) Profile, defined for 65: <bind>
66: <bindParam/>
DTV. 67: </bind>
Figure 1 shows an almost complete NCL ele- 68: </link>
ment tree. Figure 3 exemplifies an NCL applica- 69: </body>
tion, discussed below to clarify concepts and to 70: </ncl>
illustrate the use of NCL elements.
The NCL Structure module defines the root Figure 1. Structure of NCL documents.

76 IEEE Communications Magazine • June 2010


GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 77

may have <port>, <property>, <media>,


<context>, <switch>, and <link> elements
as its children. The <meta> and <metadata>
elements, omitted in Fig. 1, may be child ele-
ments of <head>, <body>, and <context>
elements. The <body> element is treated as a
context object, as defined in what follows.
The <media> element defines a media object
specifying its type and content location. Some
special types are predefined by the language:
application/x-ncl-settings type, speci-
fying an object whose properties are global vari-
ables defined by the application author or
reserved environment variables manipulated by
an NCL user agent; application/x-ncl-
time type, specifying a <media> element whose Figure 2. NCL multidevice application.
content is the Universal Time Coordinated
(UTC); application/x-ncl-NCL type speci-
fying a <media> element whose content is trated in Fig. 2 and discussed afterward. Each
another NCL embedded application; and imper- <region> may contain another set of nested
ative media object types application/x- <region> elements, and so on, recursively;
ncl-NCLua and regions define areas (e.g., screen windows), and
application/x-ncl-NCLet, specifying are referred to by <descriptor> elements, as
<media> elements whose content is a code span previously mentioned.
written in Lua or Java languages, respectively. A <causalConnector> element represents
The <context> element defines a context a relation that may be used for creating <link>
object. A context is a composite that contains a elements. In a causal relation, a condition role
set of objects (media, context, or switch) and a shall be satisfied in order to trigger an action
set of links. Like the <body> element, <con- role. Conditions and actions are defined as chil-
text> elements may have <port>, <proper- dren of <link> elements. A <link> element
ty>, <media>, <context>, <switch>, and binds (through its <bind> elements) an object’s
<link> child elements. interfaces to connector roles (conditions or
The <switch> element allows for the defini- actions), defining a spatiotemporal relationship
tion of alternative objects (represented by among objects (<media>, <context>,
<media>, <context>, and <switch> ele- <body>, or <switch> elements).
ments) to be chosen in presentation time. Test The <descriptorSwitch> element con-
rules used for choosing the switch component tains a set of alternative descriptors to be associ-
are defined by <rule> or <compositeRule> ated with media objects. Analogous to the
elements that are grouped by the <ruleBase> <switch> element, the <descriptor-
element, defined as a child of the <head> ele- Switch> choice is done during document pre-
ment. sentation, using test rules defined by <rule> or
NCL allows defining object interfaces that <compositeRule> elements.
are used in relationships with other object inter- The <importBase> element allows any
faces. The <area> element allows the definition base to incorporate another already defined
of a content anchor representing a spatial, tem- external base. Additionally, NCL documents may
poral, or spatiotemporal segment in a media be imported as a whole through <importNCL>
object’s (<media> element) content, or a code elements. The <importedDocumentBase>
span in imperative media objects. The <prop- element specifies a set of imported NCL docu-
erty> element is used for defining object prop- ments, and shall also be defined as a child ele-
erties (local variables) or a group of object ment of the <head> element.
properties as one of the object interfaces. The Some important NCL elements’ attributes are
<port> element specifies a composite (<con- defined in other NCL modules. The EntityReuse
text>, <body>, or <switch> element) port module allows an NCL element to be reused
together with its respective mapping to an inter- [21]. This module defines the refer attribute,
face of one of the composite child components. which identifies the element that will be reused.
The <switchPort> element allows the cre- Only <media>, <context>, <body>, and
ation of <switch> element interfaces that are <switch> may be reused. The KeyNavigation
mapped to a set of alternative interfaces of the module provides extensions necessary to describe
switch’s internal objects. focus movement operations (navigation control)
The <descriptor> element specifies tem- among media objects. The Animation module
poral and spatial information needed to present provides the necessary extensions to describe
each media object. The element may refer to a what happens when a property value is changed.
<region> element to define the initial position The change may be instantaneous, but it may
of a <media> element in some output device. also be carried out during an explicitly declared
The set of descriptors of a document is defined duration, either linearly or step by step. The
inside the <descriptorBase> element, a Animation module defines attributes that may
child of the <head> element. Also inside the be incorporated by actions, defined as child ele-
<head>, the <regionBase> element defines a ments of <causalConnector> elements.
set of <region> elements for a given class of The NCL <transitionBase> element
devices in a multidevice environment, as illus- specifies a set of transition effects, defined by

IEEE Communications Magazine • June 2010 77


GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 78

<transition> elements, and shall be defined device screen. Lines 10 to 12 define the
as a child element of the <head> element. Tran- “advertRg” region as filling the whole “sys-
sition effects can be applied at the beginning or temScreen(2)” secondary display. Lines 13 to
end of a media object presentation, as defined in 18 define the descriptor base, whose
attributes of the <descriptor> element asso- <descriptor> elements define in which region
ciated with the media object. each related media object will be exhibited. The
In order to illustrate an NCL use case, “iconDs” descriptor also specifies the explicit
assume the following simple application: during duration of 40 s for the icon exhibition.
a soccer game animation, an advertisement, tem- Lines 19 to 29 define the connector base. The
porally related with a special scene of the anima- causal connector “onBeginStart” has its con-
tion, is presented, allowing a viewer to interact dition satisfied when a media object’s anchor
to buy the product (soccer shoes). In order to starts its presentation, triggering, as a result, the
avoid annoying other viewers, the interaction starting presentation action on another media
processes will not be exhibited on the TV screen, object’s anchor. The causal connector “onKey
but on secondary device screens, for example, SelectionStart” specifies that the selection
mobile phones. Figure 2 illustrates this applica- of a media object’s anchor, by pressing a key,
tion. The complete NCL code is presented in triggers the starting presentation action on
Fig. 3. another media object’s anchor.
In Fig. 3, lines 5 to 9 define two regions in The <body> element defines the document
the base device (the TV set). The “main- structure. The port in line 32 states from which
ScreenRg” region occupies the whole display media object the document presentation initiates
and the “iconRg” region (with zIndex=“1”) (in this case, the “video” media object). The
overlays the previous region (default zIn- “video” media object (lines 33 to 36) is
dex=“0”) in the bottom right corner of the received from
“rtp://www.ginga.org.br/video.
mp4” to be presented in full screen, as defined
1: <?xml version=”1.0” encoding=”ISO-8859-1”?> by its descriptor. The “icon” is an imperative
2: <ncl id=”merchandisingDocument” media-object with Lua code, implementing a
3: xmlns=”http://www.ncl.org.br/NCL3.0/EDTVProfile:> blinking soccer shoes image. The “advert”
4: <head> media object (lines 39 and 40) is an XHTML
5: <regionBase>
6: <region id=”mainScreenRg”/> content to be presented on secondary devices.
7: <region id=”iconRg” bottom=”10%” right=”10%” Lines 41 to 45 define the first relationship,
8: width=”20% height=”20%” zIndex=”1”/> stating that the “icon” media object must start
9: </regionBase> its exhibition as soon as the “iconA” temporal
10: <regionBase device=”systemScreen(2)”>
11: <region id=”advertRg”/> anchor of the “video” media object begins its
12: </regionBase> presentation. Lines 46 to 50 specify another rela-
13: <descriptorBase> tionship, establishing that a viewer interaction
14: <descriptor id=”mainScreenDs” region=”mainScreenRg”/> with the “icon” image pressing the remote
15: <descriptor id=”iconDs” region=”iconRg”
16: explicitDur=”40s”/> control RED key must start “advert” media
17: <descriptor id=”advertDs” region=”advertDs”/> object presentation (a purchase web page) on
18: </descriptorBase> secondary devices.
19: <connectorBase> The Lua code that carries out the soccer
20: <causalConnector id’”onBeginStart”>
21: <simpleCondition role=”onBegin”/> shoes animation is presented in Fig. 4.
22: <simpleAction role=”start”/> The isON and stop flags (line 1) control
23: </causalConnector> when the soccer shoes icon is presented and
24: <causalConnector id=”onKeySelectionStart”> when the animation stops, respectively. The
25: <connectorParam name=”keyCode”/>
26: <simpleCondition role=”onSelection”key=”$keyCode”/> function myBlinkAnimation is used to
27: <simpleAction role=”start”/> redraw the canvas, performing the blink effect
28: </causalConnector> on the icon. The function starts getting the can-
29: </connectorBase> vas size (line 3), draws a rectangle filling the
30: </head>
31: <body> canvas (line 4), and then combines the soccer
32: <port id=”mainP” component=”video”/> shoes image with the canvas, depending on the
33: <media id=”video” descriptor-”mainScreenDs” isON flag value (lines 5 to 7). Line 8 updates
34: src=”rtp://www.ginga.org.br/video.mp4”> the isON flag, and line 9 calls the canvas flush,
35: <area id=”iconA” begin=”10s” end=”50s”/>
36: </media> in order to update the screen. Line 10 calls
37: <media id=”icon” descriptor=”iconDs” myBlinkAnimation every 1000 ms, while
38: src=” blinkAnimation.lua”/> stop flag is true.
39: <media id=”advert” descriptor=”advertDs” The NCLua API defines an event-oriented
40: src=”http://www.ginga.org.br/buy.xhtml”/>
41: <link xconnector=”onBeginStart”> communication between NCL and Lua codes.
42: <bind role=”onBegin” component=”video” When the Lua object is started, line 18 registers
43: interface=”iconA”/> an event handler for the stop presentation event
44: <bind role=”start” component=”icon”/> to be received from NCL, and starts the blinking
45: </link>
46: <link xconnector=”onKeySelectionStart”> animation (line 19), calling the myBlinkAni-
47: <linkParam name=”keyCode” value=”RED”/> mation function. When an NCL link stops the
48: <bind role=”onSelection” component=”icon”/> Lua object, a “stop” event is received and
49: <bind role=”start” component=”advert”/> treated by lines 13 to 16.
50: </link>
51: </body>
52: </ncl>
THE GINGA-NCL ARCHITECTURE
Figure 3. NCL application code. Ginga-NCL was initially proposed for terrestrial

78 IEEE Communications Magazine • June 2010


GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 79

DTV systems. Then the same architecture and


facilities were applied to IPTV. The modular 1: local isON, stop = true, false
architecture of Ginga-NCL also allows for its use 2: function myBlinkAnimation()
3: local w,h = canvas:attrSize()
with other transport systems (e.g., satellite and 4: canvas:drawRect(’fill’, 0, 0, w, h)
cable TV). Figure 5 depicts the Ginga-NCL 5: if isON then
components and how they relate with other com- 6: canvas:compose(0, 0, canvas:new(”soccer_shoes.png”))
ponents of a general IPTV architecture. 7: end
8: isON = not isON
The Ginga-NCL Presentation Engine is a log- 9: canvas:fluch()
ical subsystem responsible for running NCL 10: if not stop then event.timeer(1000, myBlinkAnimation) end
applications. The core of the Presentation 11: end
Engine is the Formatter. This component is in 12: function handler(evt)
13: if evt.class == ‘ncl’ and evt.type == ‘presentation’
charge of receiving and controlling multimedia 14: and evt.action == ‘stop’ then
applications written in NCL. Applications are 15: stop=true
delivered to the Formatter by the Ginga Com- 16: end
mon Core (Ginga-CC) subsystem. 17: end
18: event.register(handler)
Upon receiving an application, the Formatter 19: myBlinkAnimation()
requests the XML Parser and Converter compo-
nents to translate the NCL specification to the Figure 4. Lua application code.
Ginga-NCL internal data structures necessary
for controlling the application presentation.
From then on, the Scheduler component is start-
ed in order to orchestrate the presentation. The values to be assigned to NCL <property> ele-
prefetching of a media object’s content, the eval- ments.
uation of link conditions, and the scheduling of The Ginga-NCL Presentation Engine sup-
corresponding link actions that guide the presen- ports multiple presentation devices through its
tation flow are tasks performed by the Sched- Layout Manager component. This component is
uler. In addition, the Scheduler is responsible for responsible for mapping all regions defined in an
commanding the Player Manager component to NCL application to regions on exhibition devices.
instantiate appropriate players, according to the The Context Manager component of Ginga-
media content types to be exhibited. Media con- CC is responsible for gathering platform charac-
tents are acquired through the protocol stack, teristics and viewer profiles into a database used
and they can come from different communica- to update an NCL application’s global variables
tion networks. defined in the NCL settings object, presented in
A generic API establishes the necessary the previous section. This information can then
communication between players and the Pre- be used to adapt an application.
sentation Engine (Scheduler component). The display graphical model defined by the
Thanks to this API, Ginga-NCL and Ginga-CC receiver platform is maintained by the Graphics
are strongly coupled but independent subsys- Manager component, which is in charge of han-
tems. Ginga-CC can be substituted by other dling operations on graphic planes and zIndex
third party implementations for IPTV engines, overlay requests.
allowing Ginga-NCL to be integrated with The Data Processing component offers sup-
other IPTV middleware, extending their func- port for acquiring data transported in DSM-CC
tionalities with facilities to support NCL DTV carousels [10] or other pushed data protocols.
applications. The Persistency component is in charge of every
Players are responsible for notifying the Pre- data storage management requested by applica-
sentation Engine of events defined in NCL appli- tions. The Tuner component is responsible for
cations, that is, when a media segment (an offering an API for RF or IPTV channel man-
anchor) begins or ends its presentation, or when agement (broadcast RF frequency tuning or
it is selected. Players that do not follow the multicast group entry, respectively). The Search
generic API must use the services provided by Engine component can be activated by an elec-
Adapters. tronic program guide (EPG) or another service
In Ginga-NCL a DTV application can be that needs data mining. Security management is
generated or modified on the fly using NCL performed by the DRM and Conditional Access
editing commands. The Presentation Engine (CA) components. Finally, each component of
deals with NCL applications collected inside a Ginga can be updated through the Update Man-
data structure known as a private base. A Pri- ager component.
vate Base Manager component is in charge of IPTV-specific services, such as VOD and
receiving NCL editing commands and maintain- datacasting, are outside the Ginga-NCL scope.
ing the NCL documents being presented. NCL However, an API is defined offering NCL ser-
editing commands [3] are divided into three sub- vices to these IPTV service components. Thus, a
sets. The first one focuses on private base activa- VoD service can, for example, play an NCL
tions and deactivations (openBase, activate DTV application besides the main audiovisual
Base, deactivateBase, saveBase, and stream requested. In addition, a whole VoD ser-
closeBase commands). In a private base NCL vice can be written in NCL/Lua, as well as other
applications can be started, paused, resumed, IPTV services like widget portals, gaming, and
stopped, and removed, through well defined EPGs.
editing commands that compose the second sub-
set. The third subset defines commands for
updating an application on the fly, allowing NCL
FINAL REMARKS
elements to be added and removed, and allowing The Ginga-NCL open source reference implemen-

IEEE Communications Magazine • June 2010 79


GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 80

There are several IPTV Services/Applications Ginga-NCL presentation engine


XML parsers
commercial Formatter
VoIP EPG NCL context Converters
implementations of manager Scheduler
Gaming Bridge
Ginga-NCL for Player Private base
manager Layout manager manager
terrestrial set-top PPV VOD
boxes. Some of
them also offer Adapters
Ginga Common-Core
support to IPTV Persistency Context manager

platforms. Some CA Search engine Update manager


Data Players
commercial set-top DRM processing Tuner G. manager
boxes plan to offer
Ginga-NCL support Protocol stack

both for IPTV and SI MPE DSM-CC Media streams


FTP HTTP RSTP RTCP
for satellite TV. IGMP TS and others
RTP

TCP UDP
IP

Figure 5. The Ginga-NCL architecture for IPTV platforms.

tation can be obtained from http://www.ncl.org.br. and suitable solution in such a hybrid scenario
There are several commercial implementa- where harmonization is desirable and now
tions of Ginga-NCL for terrestrial set-top boxes. demanded.
Some of them also offer support for IPTV plat-
forms. Some commercial set-top boxes plan to REFERENCES
offer Ginga-NCL support for both IPTV and [1] ABNT NBR, “Digital Terrestrial Television — Data Coding
satellite TV. and Transmission Specification for Digital Broadcasting
In agreement with the ITU-T multimedia — Part 2: Ginga-NCL for Fixed and Mobile Receivers —
application framework for IPTV [22], this article XML Application Language for Application Coding”;
http://www.abnt.org.br/imagens/Normalizacao_TV_Digi-
proposes Ginga-NCL integration with third party tal/ABNTNBR15606-2_2007Ing_2008.pdf
IPTV middlewares, extending their API to sup- [2] R. Ierusalimschy, Programming in Lua, 2nd ed., Lua.org,
port NCL DTV applications. The integration 2006.
can be done through adapting Ginga-CC to [3] ITU-T Rec. H.761, “Nested Context Language (NCL) and
Ginga-NCL for IPTV Services,” Geneva, Apr. 2009.
IPTV platforms or adapting the third-party [4] S. Morris and A. Smith-Chaigneau, Interactive TV Stan-
IPTV middleware’s core to provide the API dards: A Guide to MHP, OCAP, and JavaTV, Focal Press,
requested by Ginga-NCL. 2005.
Several advantages come from Ginga-NCL [5] ETSI Std. TS 102 812, “Digital Video Broadcasting
(DVB), Multimedia Home Platform (MHP) Specification,”
integration to IPTV platforms. First, Ginga-NCL v. 1.1.1, 2003.
provides a powerful declarative language target- [6] ATSC Std., “Advanced Application Platform (ACAP),”
ed to the DTV application domain, unlike all Doc. A/101, 2005.
other DTV declarative middleware specifica- [7] ARIB STD-B24 v. 3.2, “Volume 3: Data Coding and Trans-
mission Specification for Digital Broadcasting,” 2002.
tions, which are based on general-purpose lan- [8] “IPTV Middleware Market Dynamics,” Light Reading
guages or web technologies. Insider, vol. 6, no 9.
Second, NCL applications are easier to design [9] Microsoft, “Microsoft Mediaroom”; http://www.microsoft.
and usually do not require programming exper- com/mediaroom/
[10] Minerva Networks; http://www.minervanetworks.com
tise, as imperative language approaches do. [11] Orca Interactive; http://www.orcainteractive.com
Imperative approaches occasionally put applica- [12] Myrio and Nokia Siemens Networks; http://www.
tion portability at risk, presentation control is myrio.com
much more difficult to achieve as a rule, and [13] Soft At Home; http://www.softathome.com
[14] Jornada en la Cátedra Alcatel-Lucent, “IPTV Trends,”
they are more prone to errors committed by Madrid, Spain 2009.
application programmers. [15] ITU-T Rec. H.762, “Lightweight Interactive Multimedia
Third, an expressive declarative language Environment,” Geneva, Dec. 2009.
such as NCL can support almost all usual DTV [16] HbbTV, “HbbTV Overview,” EBU/ETSI Hybrid Broadcast
Broadband Wksp., Amsterdam, 2009.
applications, and for those that do not match the [17] The Project Canvas Wiki; http://www.projectcanvas.
NCL model focus, NCL supports the efficient co.uk
and lightweight Lua scripting language. [18] Verizon FiOS TV Development Resources; https://www22.
Finally, it is possible to build hybrid receivers verizon.com/fiosdeveloper/General/Resource.aspx
[19] ISO/IEC 14496-20, “Lightweight Application Scene
supporting both terrestrial DTV and IPTV (and Representation (LASeR) and Simple Aggregation Format
other DTV systems as well), decreasing receiver (SAF),” 2006.
costs and offering both services to users. The [20] W3C Rec., “Scalable Vector Graphics — SVG 1.1 Speci-
glue-language approach of NCL is an efficient fication,” 2003; http://www/w3/org/TR/SVG11

80 IEEE Communications Magazine • June 2010


GOMES SOARES LAYOUT 5/18/10 11:46 AM Page 81

[21] L. F. G. Soares and C. S. Soares Neto, “Nested Context where since 1990 he has headed the TeleMídia Lab. He is a
Language 3.0 — Reúso e Importação,” tech. rep., Infor- board member of the Brazilian Internet Steering Commit-
matics Dept., no. 33, 2009. tee and Chair of the Middleware Working Group for the
[22] ITU-T Rec. H.760, “Overview of Multimedia Application Brazilian Digital TV System.
Frameworks for IPTV,” Geneva, Apr. 2009.
[23] ITU-R Rec. BT-1699, “Harmonization of Declarative M A R C I O F E R R E I R A M O R E N O (mfmoreno@inf.puc-rio.br)
Content Format for Interactive TV Applications,” Gene- received his M.Sc. degree from the Informatics Department
va, 2009. of PUC-Rio, Brazil, in April 2006. At present, he is a Ph.D.
student at PUC-Rio and an associate researcher in the
TeleMídia Lab. He has worked on the terrestrial Brazilian
ADDITIONAL READING DTV specifications and the Ginga-NCL reference implemen-
[1] ISO/IEC Std. 13818-6, “Information Technology — tation.
Generic Coding of Moving Pictures and Associated
Audio Information — Part 6: Extensions for DSM-CC,” CARLOS DE SALLES SOARES NETO (csalles@inf.puc-rio.br) is an
1998. assistant professor at the Federal University of Maranhão
(UFMA). He received his M.Sc. degree from the Informatics
Department of PUC-Rio in August 2003. At present, he is a
BIOGRAPHIES Ph.D. student at PUC-Rio and an associate researcher in the
TeleMídia Lab. He has worked on the terrestrial Brazilian
LUIZ FERNANDO GOMES SOARES (lfgs@inf.puc-rio.br) is a full
DTV specifications.
professor in the Informatics Department of the Pontifical
Catholic University of Rio de Janeiro (PUC-Rio), Brazil,
M ARCELO F ERREIRA M ORENO (moreno@inf.puc-rio.br) is an

CALL FOR PAPERS


NETWORK TESTING SERIES
The objective of the Network Testing Series of IEEE Communications Magazine is to provide a forum across the academia and the
industry to address the design and implementation defects unveiled by network testing. In the industry, testing has been a mean to
evaluate the design and implementation of a system. But in the academia, a more common practice is to evaluate a design by mathe-
matical analysis or simulation without actual implementations. A less common practice is to evaluate a design by testing a partial
implementation. That is, the academia focuses more deeply on algorithmic design evaluation while the industry has broader concerns
on both algorithmic design issues and system implementation issues. Often an optimized algorithmic component could not guarantee
the optimal operation of the whole system when other components throttle the overall performance.
This series thus serves as a forum to bridge the gap, where the design or implementation defects found by either community could
be referred by another community. The defects could be found in various dimensions of testing. The type of testing could be function-
ality, performance, conformance, interoperability and stability of the systems under test (SUT) in the lab or in the field. The SUT could
be black-box without source code or binary code, grey-box with binary code or interface, or white-box with source code. For grey-box
or white-box testing, profiling would help to identify and diagnose system bottlenecks. For black-box testing, benchmarking devices of
the same class could reflect the state of the art. The SUT could range from link-layer systems such as Ethernet, WLAN, WiMAX, 3G/4G
cellular, and xDSL, to mid-layer switches and routers, upper-layer systems such as VoIP, SIP signaling, multimedia, network security,
and consumer devices such as handhelds. In summary, the Network Testing Series solicits articles falling in, but not limited to, the fol-
lowing topics:
• Testing functionality, performance, conformance, interoperability, and stability
• Testing systems and services of 10G Ethernet, Power over Ethernet, WLAN, WiMAX, 3G/4G cellular, xDSL, switches, routers, IPv6,
VoIP, SIP signaling, storage area networks, network security, and consumer handhelds
• Testing various layers of network devices including black-boxes, white-boxes, and grey-boxes
• Benchmarking and profiling network systems and services
• Network lab testing and field testing
• Designing network test methodologies, test tools, and test beds
• Evaluating false positive and negative of network security
• Analyzing lab-found and customer-found defects
SUBMISSION
Prospective authors are strongly encouraged to contact the Series Editors before writing and submitting an article in order to
ensure that the article will be appropriate for the Series. The submitted articles should not be published elsewhere or be under review
for any other conference or journal. Articles should be tutorial yet rigorous in nature. Mathematical equations should not be used
(although some simple equations may be allowed if permission is granted by the Series Editor and the Editor-in-Chief). Articles should
not exceed 4500 words. Figures and tables should be limited to a combined total of six. Complete guidelines for prospective authors
can be found at: http://dl.comsoc.org/livepubs/ci1/info/ sub_guidelines.html.
Please send PDF (preferred) or MSWORD formatted papers to Manuscript Central (http://mc.manuscriptcentral.com/ commag-ieee), reg-
ister or log in, and go to the Author Center. Follow the instructions there, and select the topic "Network Testing Series." Since this is a
regular series, papers can be submitted at any time for consideration for subsequent issues.
SCHEDULE
2~3 issues per year with submissions at any time

SERIES EDITORS
Ying-Dar Lin Erica Johnson Tom McBeath
ydlin@cs.nctu.edu.tw erica.johnson@iol.unh.edu Tom.McBeath@spirent.com
National Chiao Tung University University of New Hampshire Spirent Communications Inc., USA
Network Benchmarking Lab (NCTU-NBL), Taiwan InterOperability Lab (UNH-IOL), USA

IEEE Communications Magazine • June 2010 81