NISTIR 6740 

Proceedings of the 

2nd Annual Digital TV Applications Software Environment 

 (DASE) Symposium 2001: End-to-End Data Services, 

 Interoperability & Applications 

Edited by: 

 Alan Mink

Robert Snelick 

 Information Technology Laboratory

June 2001 

National Institute of Standards and Technology 

Technology Administration, U.S. Deportment of Commerce 

U.S. Department of Commerce

 Donald L Evans, Secretary 

National Institute of Standards and Technology

 Karen H. Brown, Acting Director 
Table of Contents 

Foreword ..................................................................................................................................... vi

Symposium Committee ................................................................................................................................ vii

Opening Remarks 

 Welcome to NIST 

 Alan Mink 

 A TSC Introduction 

 Marker Richer, 

 Executive Director. Advanced Television Systems Committee (ATSC) 

 1st Day Keynote 

 Gloria Tristani, 

 Commissioner, Federal Communications Commission (FCC) 

 ATP at NIST 

 Marc Stanley, 

Acting Director, Advanced Technology Program (ATP) 

 2nd Day Keynote 

 Christopher Atienza. 

 Associate Director of Technology, Public Broadcasting System (PBS) 

Session 1: DASE Components

DASE Overview, Architecture & Common Content Types...............................................................1 

 Glenn Adams (ATSC T3/SI7 Acting Chair), 

 XFSI, Inc 

DASE Declarative Applications & Environment .............................................................................31 

 Glenn Adams (ATSC T3/SI7 Acting Chair), 

XFSI, Inc 

DASE API Object Model & Examples of Use .................................................................................55 

 Petr Peterka (Former A TSC T3/S 17 Vice-chair and DASE API Architect). 

 Senior Staff Engineer -Broadband Communication Sector, Motorola 

Session 2: DASE Infrastructure

Java TV 1.0 API Technical Overview ..........................................................,. ................................. 73

 Jim VanLoo, 

 Staff Engineer -JavaTV, Sun Microsystems 

ATSC Digital Television MPEG-2, PSIP and Data Broadcast......................................................... III

 Rich Chemock, 

 mM Corp. 

Architectural Reference Model ...................................................................................................... 149

 Mike Dolan (ATSC T3/SI8 chair). 

 Industry Consultant 

iii 
Session 3: DASE Framework & Implementation 

DASE Security Framework...........................................................................................................165 

 Taylor Kidd, 

 OpenTV 

NIST DASE Development Environment ..........................................................................167 

 Rob Snelick, 

 National Institute of Standards and Technology 

An Automated Approach for DASE Conformance Testing............................................................185 

 Andrew Twigger. 

 Head Engineering Team, Unisoft Corp. 

Session 4: Infrastructure

ORBIT -Object Reconfigurable Broadcast using IT....................................................................... 199 

Pedro Botelho Cardoso, 

 INESC 

Exchange Format Handling the Material (MXF)............................................................................ 219 

 Vitor Manuel Teixeira, 

 INESC 

An Optimal File Distribution Model for Data Broadcasting .......................................................... 241 

 Edwin Heredia, 

 Microsoft Corp 

Session 5: Related Standards 

Data Broadcasting Standards Overview........................................................................................ 255 

 Mike Dolan (ATSC T3/S18 chair). 

 Industry Consultant 

DVB-MHP: Technical Overview and Commercial Status ........................................................... 273 

 Hervé Creff, 

 GM. Product Marketing. CANAL+ TECHNOLOGIES 

Open Cable Application Platform Overview ................................................................................ 390 

 Don Dulchinos, 

 Vice President Advanced Platforms & Services. Cable Labs 

Session 6: Platform Users 

Audience Measurement................................................................................................................... 283

 William Feininger. 

 Neilsen Media 

A Managed Media Service Platform............................................................................................... 285

 Ravi Gauba and Klaus Hofrichter 

 Sony Electronics 

SMPTE 292M VANC A PRACTICAL WAY TO HANDLE 'STICKY' DATA........................... 295

 Jim Carruthers. 

 President, Norpak Corp 

iv 
Session 7: Applications

Components and Advanced Functionalities of the Next Generation Interactive

Programming Guide..................................................................................................................... 307 

Yakov Kamen, 

iSurfTV 

SMPTE Declarative Data Essence: Comparison to ATSC DASE .............................................. 317 

John BarkIey, et al. 

National Institute of Standards and Technology 

Mass Customization of DASE Broadcast and Increased Advertisement Capacity ..................... 331 

Eddie Schwalb, 

Sharp Labs of America 

Session 8: Platform Services

Comprehensive Public Key Infrastructures and the Realm of DASE Security............................ 347 

 Edwin Heredia, 

 Microsoft Corp 

Aggregating DASE Applications.................................................................................................. 359 

 Eddie Schwalb, 

Sharp Labs of America 

Integration of a RETE Based Rule Engine into the DASE Environment..................................... 377 

 Pourya M. Dehnadi, 

 Apex Logic, Inc. 

v 
Foreword

As the co-chairs of the DASE Symposium 2001, we would like to welcome you to this second

symposium in this continuing series. Once again we have the pleasure of holding the DASE

Symposium 2001 at the National Institute of Standards and Technology just outside Washington,

D.C., our nation's capital. 

The emergence of interactive digital television (DTV) brings about a host of exciting

opportunities for broadcasters, content providers, tool developers, and equipment

manufacturers. Interactive DTV combines aspects of traditional television and the Internet that

inspires applications in e-commerce, e-learning, targeted advertising, video-on-demand, and

enhanced viewing services. As the various standards organizations and consortiums hone their

lower layer standards for interactive Digital TV, we find that although they derive from common

roots they are evolving along different lines. The results are similar but non-interoperable

standards for different technologies and different regions. Because of this, interest has shifted to

the newly emerging middleware layer standards being developed by the Advanced Television

Systems Committee (ATSC) Digital TV Application Software Environment (DASE) specialist

group in the USA and Digital Video Broadcast (DVB) Media Home Platform (MHP) in Europe

as both an enabling and unifying technology to obtain standardized interactive Digital TV content

and behavior. As these middleware layer standards traverse the balloting and acceptance process,

it is important to provide more detailed information on their structure, anticipated use scenarios,

possible additional features and potential harmonization. That is the purpose of this symposium

series. Although our focus at this symposium is on DASE, we have contributions from DVB, the

Cable industry, SMJ7rE and others. We hope that the DASE Symposium 200lwiII help to bring

about global harmonization in this middleware layer and that future symposiums in this series

will focus more broadly on this generic layer. 

We hasten to mention that although significant work has been accomplish in the DASE

consortium and the structure of the standard is fairly mature, it is important to note that the

standard is not finalized and is a work-in-progress. 

We would like to thank the speakers for their contributions to this excellent symposium program

and, also where applicable, to the DASE effort. We would also like to thank the symposium

committee for their hard work and our co-sponsors, ATSC, for their support all of which helped

to make this event possible. As most of you already know, putting such a symposium together is

an arduous task. 

Alan Mink CoChair, DASE 2001 

Rob Snelick CoChair, DASE 2001 

vi
Symposium Committee 

Co-Chairs 

 Alan Mink 

Rob Snelick 

National Institute of Standards and Technology 

Publication Chair 

Jennifer Quinn 

National Institute of Standards and Technology 

Exhibit Chair 

Christy Kehlbek 

Advanced Television Systems Committee 

Local Arrangements Chair 

 Patrice Boulanger 

National Institute of Standards and Technology

Registration Chair 

 Kimberly Snouffer 

National Institute of Standards and Technology

vii 
DASE Overview, Architecture & Common Content Types 

Glenn Adams 

XFSI, Inc 

glenn@xfsi.com 

This talk introduces DASE to newcomers. Basic vocabulary such as 'application' and 'application

environment' are defined. General approaches to application deployment are discussed along with key

problems. The approach adopted by DASE to these problems is described. A general overview of DASE

content and a DASE system is presented along with the status of the draft DASE standard and the schedule

for its completion. The expected evolution of DASE as a series of standards is introduced. Outstanding and

ongoing problems related to DASE are highlighted. 

Building on the introduction, a more detailed review of the DASE content and system architectures

are described. The common facilities of both types of application environments are described in some level

of detail. 
Introduction to DASEGlenn AdamsChair ATSC T3/S17
Why DASE?

• The Holy Grail

! Standardized Interactive Televisi

Content and Behavior

• Useful Side Effects

! Validate utility and design of A/90 

Broadcast Standard
General Concepts

• Application

! Information which expresses beha! A program or a document

• Application Environment

! System which interprets applicatio

order to produce behavior

! A program or document processing 

system
Application Approaches

• Embedded Approach• Thin-Client Approach• Full-Client Approach
Embedded Application Appro

• Application pre-installed on rece• Generally non-portable; requires 

implementing or porting for new receivers or new technology

• Hard to change or innovate with 

applications

• Very stable, but only simple feat
Thin-Client Approach

• Application shared between serv

and receiver

• Application is executed or 

interpreted on server

• Requires low-latency, high-bandw

point-to-point communication ch

• Does not scale well
Full-Client Approach

• Application dynamically installed 

receiver through broadcast or pto-point channel

• Application executed or interpre

on receiver

• Requires more resources and gre

performance than thin-client approach
Problem #1: Installing Appli

• How to install application on rec

! If pre-installed (embedded), then 

difficult to innovate.

! If dynamically installed, then appli

must be transmitted (downloaded) receiver and prepared for processsufficient time for it to be ready process at the intended time.
Problem #2: Application For

• What form should an application take

! Form = Content Type(s)

• If procedural, then what type?

! native compiled code! portable byte code (p-code)! source code

• If declarative, then what type?

! HTML, XHTML, SMIL, SVG, XML, MHE! graphics, fonts, ...
Problem #3: Environment

• What 

“native

” resources may an 

application reference or utilize?

! graphics, video, audio, user input 

(remote/keyboard), broadcast strnetwork, memory, processor

• How to reference or use?

! If mechanism is proprietary, then 

portability of applications cannot bmaintained.
DASE Approach to Problems

• Problem #1: Installing

! Download through broadcast strea

• Problem #2: Application Form

! Standardized form; strict conform

• Problem #3: Environment

! Standardized environment; compli
DASE System Interconnect

DASE System

Platform Services

(OS, I/O, Memory)

Audio

Broadcast DisplTransportUser Input
Application Resources

VideoAudioData APP1

APP2APP3

RES1RES2RES3
DASE Application Types

• Declarative Application• Procedural Application• Hybrid Application
DASE Declarative Applicatio

• Declarative Content Type

! XDML (XHTML Subset)

• Supporting Content Types

! CSS, ECMAScript, Graphics, etc.

• Document Object Model (DOM)• Declarative Application Environm

! System Behavior
DASE Procedural Applicatio

• Procedural Content Type

! Java

TM Class File Format

• Supporting Content Types

! Graphics, Audio, Video, etc.

• Procedural Application Environment

! Java

TM Virtual Machine

! APIs (PJAE, JMF, JavaTV

TM, HAVi UI, A

! System Behavior
DASE Hybrid Applications

• Hybrid Applications

! Declarative Using Procedural Cont

" Embedded Active Object Content (X

! Procedural Using Declarative Cont

" Synthesize Markup, Style, Script Con
DASE Content

(XHTML, CSS, ECMAScript, JavaTV Xlet, ...)

DASE System

Security Framework

Common Content Decoders

(PNG, JPEG, TrueDoc Font†, ...)

Declarative Application Environment

ECMAScript

Interpreter

XHTML

Interpreter

Cascading

Stylesheet

Interpreter

Document and Environment Object Model

API Implementation

Procedural Application Environment

Java Byte Code Interpreter

(Java Virtual Machine)

pJava, JMF, JavaTV, HAVi, DAVIC

API Implementation
DASE Levels

• Level 1 – Local Interaction

! Enhanced TV

• Level 2 – Remote Interaction

! Interactive TV

• Level 3 – Internet Enabled

! Internet TV
DASE Level One

• Basic Foundation• Broadcast Only• No Return Channel
Example DASE-1 Application

• Play Along Games

! Jeopardy

• For More Info

! Sport Stats, Product Info (e.g., lo

dealer based on user’s Zip Code), 

Weather and Traffic Updates

• Mini Program Guide
DASE Level Two

• Builds upon Level One• Return Channel• Enhanced Security Framework

! Digital Signatures! Return Channel Encryption

• Plug-Ins, Persistent Applications• T-Commerce Applications
Example DASE-2 Application

• Community Gaming

! Play Against Community of Players! Gambling (where legal)

•

“T-Commerce

”

! Instant Purchase! Coupon Printing

• Full Program Guide
DASE Level Three

• Builds upon Level Two• General Internet Content

! Must handle invalid, non well-form

content to be interoperable

• Web TV
Example DASE-3 Application

• Internet Browsing

! General Web Access

• Internet Commerce

! Banking! Investment Management! C2B, B2B
DASE Standard (1)

• Part 1: Introduction, Architecture, a

Common Facilities

• Part 2: Declarative Applications and 

Environment

• Part 3: Procedural Applications and 

Environment

• Part 4: Application Programming Inte• Part 5: Portable Font Resource
DASE Standard (2)

• Part 6: Security• Part 7: Application Delivery• Part 8: Conformance
DASE Development Schedul

• DASE-1 expected to be complet

end of 2001

• DASE-2 requirements developm

under way
Deployment Challenges

• End-to-End Issues

! Metadata! Format Conversion! Synchronization

• Interoperability

! Conformance Requirements! Compliance Testing
Distribution Issues

• Authoring Standard

! Will authors create native DASE c

format or other content to be transcoded into DASE format?

! SMPTE DDE-2

• Redistribution

! Will non-terrestrial media (cable a

satellite) distribute DASE content
Harmonization Issues

• DASE, MHP, and OCAP

! Common declarative functionality! Common procedural functionality! Many other details differ; but gen

approach and technology choices aidentical.

! Significant transport level differe
We Need Your Help

• Development of DASE Standard 

depends upon volunteer commitm

• Much more work is need to obta

of the promise of standardized 
DASE Declarative Applications & Environment 

Glenn Adams 

XFSI, Inc 

glenn@xfsi.com

This talk focuses upon the declarative application content and system provided by DASE. The key

W3C standards adopted by DASE are reviewed and their use in DASE is described in some detail. 

31
DASE Declarative ApplicatGlenn AdamsChair ATSC T3/S17
Outline

• Declarative Applications

! Pure Application! Hybrid Application

• W3C Technology Usage in DASE

! Core Technologies and Application! Related Technologies (CSS, DOM)
DASE DA – Pure

• Declarative Application (DA)

! markup, stylesheet, script content! common content types! security content types
DASE DA – Hybrid

• Hybrid Applications

! Declarative Using Procedural Cont

" Embedded Active Object Content (X

! Supported in DASE-1
Declarative Content Types

• Markup Content

! application/xdml+xml

• Stylesheet Content

! text/css

• Script Content

! text/ecmascript
Primary Content Types

• XHTML Family Document Type

! XHTML DTD Driver! XHTML Content Model

• Stylesheet Support

! Cascading Stylesheet (CSS) Level 2 Sub! Default Stylesheet

• Scripting Support

! ECMAScript! Document Object Model
XML

• What is it?

! Extensible Markup Language! SGML Subset

• Why do it?

! SGML overly complex! SGML feature abuse leads to poor pract! Strong parser requirements: more robus

• How to use it?

! Define a Document Type Definition (DT! Create and Validate Document Instance
XML Technologies Used in D

• XML 1.0• XML Namespaces• XML Stylesheet Linkage• XML Base• XML Canonicalization
Related W3C Technologies U

• Cascading Style Sheet, Level 2

! Both subsetted and extended

• Document Object Model, Level 2

! Both subsetted and extended! Both ECMAScript (3rd Edition) and 

Bindings
XHTML

• What is XHTML?

! HTML expressed as XML, not SGM

• But which HTML?

! XTHML 1.0 (HTML 4.0)! XHTML 1.1 (HTML 4.0 subset plus ! XHTML Basic (~HTML 3.2)
XHTML Modularization

• What is it?

! Division of XHTML 1.0 DTD into Module! Modules define Entities, Elements, Elem

Content Models and Attributes

• Why do it?

! Improves reusability; supports customiz

(subsets, supersets)

• How to use it?

! Select Modules and Content Models
XDML

• XDML

! Extensible DTV Markup Language! Defines application/xdml+xml content ty

• DTD Driver Selects Modules

! Select modules which provide orthogona

functionality

• Content Model Entities

! Defines what can appear as the content 

element type
XHTML Modularization Use

• Two Document Types

! Standard 

– Host Language Conform

! Frameset 

– Integration Set Confo

• Full UA Conformance Not Requir

! Clauses 4-6 Not Required

" Can reject unknown element, attribut

attribute value; i.e., can abort if not v

• Excludes Certain Modules
Included XHTML Modules

• bidirectional• client-side image map• forms• frame• hypertext*• intrinsic events• list*• meta• name identification

• object• presentation• scripting• structure*• style• style attribute• tables• target• text*
Excluded XHTML Modules

• applet

! use <object>

• base

! use xml:base

• basic forms• basic tables• edit• iframe

• image

! use <object>

• legacy

! use style attri

rule

• link

! use xml-styles

• server side ima
Excluded Element Types

• applet• base• basefont• center• del• dir• font• iframe

• img• ins• isindex• link• menu•

s

•

u
Stylesheet Support

• Cascading Stylesheets

! Level 2 Grammar! All Level 1 Properties! Some Level 2 Properties! Some Level 2 Property Value Exte! Some ATSC Specific Extensions

• Default Stylesheet
Using Stylesheets

• External Stylesheet

! Uses

<?xml-stylesheet href=“...”?>

• Internal Stylesheet

! Uses <style>...</style>

• Anonymous Style Rules

! Uses 

“style

” attribute, e.g.,

<p style=

“{color=red}

”

>...</p>
CSS2 Subset (1)

• Includes all CSS1 properties• Includes subset of new CSS2 proper

! border-{bottom,top,left,right}-{color,st! bottom, top, left, right, z-index! caption-side! clip, overflow! content, counter-{increment,reset}! outline, outline-{color,style,width}! position! visibility
CSS2 Subset (2)

• Partial Property Semantics

! display, font

" CSS1 values only plus ‘inherit’

! list-style-type

" CSS1 values plus ‘decimal-leading-zer

‘lower-latin’, ‘upper-latin’, and ‘inher

! text-decoration

" CSS2 values minus ‘blink’
CSS Subset (3)

• Includes all CSS2 selectors exc

! adjacent sibling! child! :first-child pseudo-class! :hover pseudo-class! :lang pseudo-class
CSS Subset (4)

• Partial @font-face rule semanti

! ‘font-family’, ‘font-style’, ‘font-v

‘font-weight’, ‘font-stretch’, ‘fon

descriptors

! ‘unicode-range’ descriptor! ‘src’ descriptor

• Excludes @page rule semantics
CSS2 Extensions

• ‘atsc-tv’ media type• ‘atsc-rgba(

r,g,b,a)’ function

• style attribute syntax

! permits inline rulesets! based on 

“Syntax of CSS rules in 

HTML’s style attribute

”, W3C Wo

Draft, 25 October 2000
Scripting Support

• ECMAScript (ECMA-262)

! Third Edition (adds exceptions, re

• (Language) Native Objects

! Global, Object, Function, Array, S

Boolean, Number, Math, Date, RegError

• Host Objects

! Document Object Model
Document Object Model

• What is it?

! A means to create and manipulate a pars

representation of a document instance (XDML document)

• Why do it?

! Content adaptation, Dynamic Style Appl

Document Synthesis

• How to use it?

! Use <script>...</script>! Use intrinsic events (e.g., onmouseover)! Use triggers
DOM2 Subset

• Excluded Modules

! CSS2 (CSS2 Extended Interfaces! Range! Traversal

• Excluded Interfaces

! Excludes all HTML Module interfa

except those required for “DOM-0

legacy script content
Included HTML Module Inter

• HTMLAnchorElement• HTMLDocument• HTMLFormElement• HTMLOptionElement• HTMLBodyElement• HTMLDOMImplementati

on

• HTMLInputEl• HTMLSelectE• HTMLCollecti• HTMLElement• HTMLObjectE• HTMLTextAr

t
DOM2 Extensions

• Adds Modules

! Legacy

• Adds Interfaces

! Adds interfaces to Core, Views, an

HTML modules
DOM2 Core Module Extensio

• DOMExceptionExt

! VALIDATION_ERR! NO_CLOSE_ALLOWED_ERR
DOM2 View Module Extensio

• DocumentViewExt

! width{Px,Mm}, height{Px,Mm}! sampleBits{R,G,B,A}! refreshOnChange
DOM2 HTML Module Extensio

• HTMLAnchorElementExt

! hash, host, hostname, pathname, port, p

search

• HTMLDocumentExt

! location, lastModified, 

{a,,v}linkColor,{bg,fg}Color, window, clea

• HTMLFormElementExt

! encoding

• HTMLObjectElementExt

! complete, lowsrc, src
DOM2 HTML Module Extensio

• HTMLTriggerObjectElementExt

! backChannel, contentLevel, source

enabled, releasable
DOM2 Added ‘Legacy’ Modu

• History

! length, back(), forward(), go()

• Location

! hash, host, hostname, href, pathname, p

protocol, search

• Navigator

! appName, appVersion, appCodeName,

userAgent, ddeBackChannel, ddeContentddeSourceId, ddeEnabled, ddeReleasab
DOM2 Added ‘Legacy’ Modul

• Window

! document, history, location, naviga! frames, length, parent, self, top, w! defaultStatus, name, opener, stat! alert(), confirm(), prompt()! setTimeout(), clearTimeout()! close(), open()
Validity and a Mutable DOM

• What is the problem?

! DOM permits mutating a valid document 

that may cause it to become invalid

! However, a series of DOM mutations, th

invalid in intermediate steps, may be valfinal step

• Current Status

! Content must insure validity 

– result is 

undefined (i.e., implementation dependennot valid
DA Design Goals

• Employ best current and emergi

practice from W3C

• High syntactic and functional

orthogonality

• Support functionality of SMPTE 

Declarative Data Essence, Level (DDE-1) through transcoding
Transcoding Requirements

• Cannot transcode script content 

to run-time script content synthe.g., eval()

• Should be able to support one-p

no look-ahead transcoding of DDto XDML in order to meet stringreal-time broadcast constraints
Transcoding Problems (1)

• document.write()

! can produce same effect as eval()! can’t transcode because may rely 

runtime state to produce results

! generates DDE-1 content! therefore, must perform transcod

receiver also; i.e., transcode outpudocument.write() prior to parsing aXDML
Transcoding Problems (2)

• Interaction of ‘name’ attribute and 

content precludes reliable translatio‘name’ into ‘id’, e.g.,<form name=‘foo’><input name=‘foo’ value=‘bar’>

</form><script>

function consMutator ( fn, en, val ){

return 

“document.

” + fn + 

“.” + en + 

“.value=” + val;

}eval ( consMutator ( ‘foo’, ‘foo’, ‘baz’ ) );</script>
Transcoding Problems (3)

• W3C has deprecated functionali

without defining alternative, e.g

! <frameset>, <frame>! <hr noshade>! <legend align=

“bottom”

>
Transcoding Problems (4)

• Style Rule vs Style Attribute

! Simple transcoding requires trans

of presentation attributes into styattributes; however,

! If style rule already applied to ele

then synthesized style attribute mconflict with precedence of style 

! Resolution requires promotion of i

style rule to stylesheet.
DASE API Object Model and Examples of Use

Petr Peterka

Motorola Broadband Communications Sector, San 

Diego, CA PPeterka@ gi.com

As DASE passed the initial balloting process, it becomes more and more important to provide not 

only reports on the design progress, updated lists of features, satisfied requirements and the basic structure of 

the API packages but also the relationships between these APIs, typical use cases and sample applications. 

There are two primary users of the DASE standard: (1) the DTV receiver implementers who will implement 

these APIs on their specific devices and (2) the content authors who will be writing applications accessing 

these APIs without any detailed knowledge of the target device. Our presentation will primarily focus on the 

needs of the content authors.

Since there are similar efforts in different realms of the TV industry, DASE decided to reuse 

existing APIs where appropriate. As a result, the DASE specification includes the following APIs: Sun's 

Java TV 1.0 and JMF 1.1 APIs, HA Vi 1.1 User Interface API, W3C DOM APIs, a subset of DA VIC 1.4 

APIs and an ATSC-specific set of APIs. All of these APIs are defined on top of the Java Virtual Machine 

and a subset of Personal Java 1.2. Personal Java provides the basic Java packages, which abstract an 

operating system; Java TV provides the core DTV receiver functionality including tuning, access to system 

and service information, data carousels, extensions to JMF, etc.; HA Vi addresses the needs of an embedded 

device with respect to a light-weight user interface; the W3C DOM API provides a bridge between the 

DASE declarative and procedural applications. Finally, DASE adds APIs for ATSC-specific features 

including PSIP (A65) and the ATSC data broadcast protocol (A90). Other extensions include support for 

application management, user management and user preferences. An Xlet, a broadcast version of an Applet, 

represents downloadable applications, which are delivered as data in the MPEG-2 transport stream together 

with audio, video and supporting data.

The DTV receiver system services that are being abstracted by the Java APIs include Network 

Communication, Content Management, Presentation and User Interface, Application and Resource

Management, Security Management, Environment Management and Utility Services.

The main focus of this presentation is not an exhaustive detailed description of all Java APIs that are 

included in the DASE standard but rather an overview of the more significant or complex packages with the 

emphases on their integrations and use cases from the content authoring point of view. We will review the 

main parts of the object model represented in UML notation and we will use sequence diagrams to show 

interaction between the Xlet and selected DASE, Java TV, HA Vi ill and Personal Java APIs. It will give 

content authors an idea of how these APIs can be used together to produce very appealing content. Main 

examples will include Xlet startup and initialization, access to data carousel files, setting up an IP multicast 

stream, working with user preferences, accessing the current service information, retrieving a list of channels 

from the PSIP database and browsing a program schedule on a given service.

55
DASE Symposium 200

DASE API Object Mode

Examples of Use

Petr Peterka

Motorola Broadband Communications Sect

19 June, 2001
19 June 2001 

Contents

1. Package Structures

– DASE Package– Java TV Package– DAVIC Package– HAVi Package– W3C Package 

2. Object Models

– DASE API Model – Java TV Model

3. Scenarios
19 June 2001 

Design Process

• Sample Applications• Definition of System Services• Reduced Set of DASE-1 Requirements• Search for Existing APIs• Call for Proposals• Selection and refinement• Mapping against Requirements• Subsetting and Constraining
19 June 2001 

Java Package Structure

java javax org

media

(from javax)

atsc

(from org)

davic

(from org)

havi

(from org)

tv

(from javax)

w3c

(from org)

Personal 

Java

Java TV

JMF

HAVi User 

Interface
19 June 2001 

DASE Packages

management

user

security

system

registry

application

si data

preferences

carousel net

graphics

descriptor

(from si)
19 June 2001 

Java TVtm Packages

locator service xlet

net media carousel

graphics util

protocol

(from media)

guide

(from service)

navigation

(from service)

selection

(from service)

tran

(from 
19 June 2001 

JMF Packages

media

(from javax)

protocol
19 June 2001 

HAVi UI Packages

ui

event

(from ui)
19 June 2001 

DAVIC Packages

media resources
19 June 2001 

W3C DOM Packages

dom

html

(from dom)

css

(from dom)

stylesheets

(from dom)

events

(from dom)
19 June 2001 

javax.tv.s

Transpor

(from tra

<<Interf

SIRetrievable

getUpdateTime()

<<Interface>>

ServiceDescription

(from navigation)

<<Interface>>

ServiceDetails

(from navigation)

<<Interface>>

Pro gramEventDescription

(from guid e)

<<Inte rface>>

ProgramEvent

(from guid e)

<<Interface>>

DataEventD

(from d

<<Interfa

DataServiceApplication

(from data)

<<Interface>>

DataServiceDescription

(from data)

<<Interface>>

ServiceComponent

(from navigation)

<<Interface>>

SIElement

getLocator()equals()hashCode()getServiceInformati onType()

<<Interface>>

DASE 

extension
19 June 2001 

javax.tv.s

ServiceNumber ge tServi ce Number()

<<In te rface>>

ServiceMinorNumber

ge tMinorNumber()

<<In te rface>>

SIManager

SIManager()createInstance()setPreferredLanguage()getPreferredLanguage()registerInterest()getSupportedDimensions()getRatingDimension()getTransports()retrieveSIElement()getService()retrieveServiceDetails()retrieveProgramEvent()filterServices()

Service

retrieveDetails()getName()hasMultipleInstances()getServiceType()getLocator()equals()hashCode()

<<In te rface>>

ServiceDescription

getServiceDescription()

(from na viga tion )

<<Interface>>

ServiceDetails

retri eveService Descri ption()ge tService Type()retri eveComp one nts()ge tProgramSchedul e()ge tL ongNa me()ge tService ()ad dServiceComp onentChangeLi sremoveService ComponentChangge tDel iverySystemType()

(from na viga tion )

<<Interface>>

ServiceComponent

getName()getAssociatedLanguagegetStreamType()getService()

(from na viga tion )

<<Interface>>
19 June 2001 

org.atsc.si

AtscTvChannel

isHidden()isVisible()

<<Interface>>

TimeSh

getTigetC

<<In

NvodReference

getShiftedChannels()

<<Interface>>

Service

(from service)<<Interface>>

ServiceDetails

(from navigation)

<<Interface>>

optionally extends

ServiceMinorNumber

(from service)<<Interface>>
19 June 2001 

ServiceDetails org.atsc

(from navigation) <<Interface>>

DataServic

getApplicagetCompatgetTitle()getPrivateDgetResourcgetResourcgetResourcgetResourc

<<Inte

DataServic

getPrivategetTitle()getApplicgetApplicgetApplicgetResouaddListenremoveLi

<<Inte

DataServiceDetails

retrieveDataServiceDescription()hasDataService()getDataSchedule()

<<Interface>>

DataSchedule

retrievePresentEvent()retrieveFutureEvent()retrieveFutureEvents()retrieveEvent()addListener()removeListener()retrieveNextEvent()getServiceLocator()

<<Interface>>

DataEventDescription

getDataEventDescription()

<<Interface>>

DataEvent

getStartTime()getEndTime()getDuration()getEventName()retrieveDescription()getRating()getChannel()

<<Interface>>

SIRetrievable

getUpdateTime()

(from service)

<<Interface>>

SIElement

getLocator()equals()hashCode()getServiceInformationType()

(from service)

<<Interface>>
19 June 2001 

Data Carousel Scenario

 : Xlet : ApplicationContext : 

DataServiceDescription

 : 

DataServiceApplica

getDataServiceDescription( )

getApplication( )

getPrivateData( )

getResourceLocator(String)

CarouselFile(Locator)

getName( )

isFile( )

addListener(CarouselFileListener)
19 June 2001 

javax.tv.xlet

XletContext

notifyDestroyed()notifyPaused()getXletProperty()resumeRequest()

<<Interface>>

Xlet

initXlet()startXlet()pauseXlet()destroyXlet()

<<Interface>>
19 June 2001 

org.atsc.application

Obje

NOSTATUS getStatesSuaddStateChremoveStategetCurrentSgetCurrentS

(from m

<<Int

ApplicationInformation

getTitle()getVersion()getRequiredProfile()getLocator()getRequiredLevel()

ApplicationRegistry <<Interface>>

registerApplication()deregisterApplication()getApplicationInformation()getApplicationProxy()getApplicationProxies()startApplication()getApplicationInformation()

<<Interface>>

ApplicationProxy

suspend()resume()getLocator()stop()

<<Interface>>

Applica

getDataSestateChanstatusCha

<<Int

Registry

getRegistryType()addRegistryListener()removeRegistryListener()

(from registry)

<<Interface>>

Xlet

(fro

<<Int
19 June 2001 

Xlet Start-up Scena

myXlet : Xlet AppManager context : 

ApplicationContext

dataService : 

DataServiceDescription

myApplication : 

DataServiceApplication

 : Inte

getApplication(Locator)

getPrivateData( )

getResourceLocator(String)

do something

initXlet(javax.tv.xlet.XletContext)

getDataServiceDescription( )

notifyDestroyed( )

getRootContainer(context)

getLocalAddress(Locator)
19 June 2001 

Receiving IP Multicast

myXlet : Xlet myApplication : 

DataServiceApplication

 : InterfaceMap 

M

getPrivateData( )

getResourceLocator...

getLocalAddress(Locator)

joinGroup(mcastAddress)

MulticastSocket(port)

setInterface(InetAddress)
19 June 2001 

org.atsc

UserRegistry

createUser()getCurrentUser()getUserNames()setCurrentUser()getUser()deleteUser()<<Interface>>

UserProfile

getName()getPreferences()authenticate()grantCapability()revokeCapability()

<<Interface>>

UserRegistryEvent

UserRegistryEventgetUserName()

RegistryListener

registryChange()(from registry)<<Interface>> RegistryChangeEven

RegistryChangeEvengetRegistryType()getCause()

(from registry)

AtscPermission

(from security)

UserPermission

UserPermission()implies()
19 June 2001 

org.atsc.prefer

RatingPreference

isBlocked()<<Interface>> PreferredLanguage

getLanguage()setLanguage()

<<Interface>>

PreferenceNam

RATING_CEILING : String = "RaLANGUAGE : String = "LanguaFAVORITE_CHANNELS : String PERSONAL_DATA : String = "P

<<Interface>

FavoriteC

getChanaddChanremoveCisFavorit<<Interfa

FavoriteServ

getName()

(from nav

<<Interfa

PersonalData

getValue()setValue()getValidKeys()

<<Interface>>

PreferencePermission

PreferencePermission()implies()

AtscPermission

(from security)

Preference

addPreferenceChangeListener()removePreferenceChangeListener()getPreferenceName()

<<Interface>>

PreferenceRegistry

getPreference()addPreference()removePreference()listPreferences()

<<Interface>>
19 June 2001 

User Preference Scenario

 : Xlet : UserRegistry : UserProfile : 

PreferenceRegistr

 : 

RegistryFactory

getRegistry(org.atsc.registry.RegistryType)

getCurrentUser( )

getPreferences( )

listPreferences( )

getPreference(String)

getLanguage(final org.atsc.preferences.LanguageScope)

addPreferenceChangeListener(org.atsc.preferences.PreferenceChangeListener)
19 June 2001 

org.atsc.se

PermissionM

AtscPermission

AtscPermission()AtscPermission()equals()getActions()hashCode()implies()

AtscAllPermission

AtscAllPermission()AtscAllPermission()implies()

AccessDeniedException

AccessDeniedException()AccessDeniedException()

Exception

(from lang)

HAViPermission

HAViPermission()HAViPermission()implies()
19 June 2001 

javax.tv.service.selection

ServiceContextFactory

ServiceContextFactory()getInstance()createServiceContext()getServiceContexts()getServiceContext()

Servic

getServ

<

ServiceConte xt

select()select()stop()destroy()getServiceContentHandlers()getService()addListener()removeListener()

<<Interface>>

Service

(from se rvice)

<<Interface>>
19 June 2001 

Discovering Current Servic

Scenario

 : Xlet : 

ServiceContextFactory

 : 

ServiceContext

A

getService( )

getServiceContext(javax.tv.xlet.XletContext)

getServiceNumber( )

getMinorNumber( )

getName( )
19 June 2001 

javax.tv.service.navi

LocatorFilter

LocatorFilter()getFilterValue()accept()

SIElementFilter

SIElementFilter()getFilterValue()accept()

Prefe

PreflistPgetFacce

ServiceTypeFilter

ServiceTypeFilter()getFilterValue()accept()

Servic

retrieveDetagetName()hasMultipleIgetServiceTgetLocator()equals()hashCode()

(from serv

<<Interfa 

ServiceIterator

toBeginning()toEnd()nextService()previousService()hasNext()hasPrevious()

<<Interfa ce>>

SIManager

(from service)

ServiceList

sortByName()sortByNumber()findService()filterServices()cre ateSe rvice Iterator()con tains()indexOf()size()getServi ce()equals()hashCode()

<<Interface>>

ServiceFilter

ServiceFilter()accept()
19 June 2001 

Service Collection Scen

 : Xlet service 

Serv

iterator : 

ServiceIterator

FilteredList : 

ServiceList

TS Filter : 

SIElementFilter

PSIP Database 

: SIManager

createInstance( )

SIElementFilter(TS)

filterServices(TS Filter)

sortByName( )

createServiceIterator( )

getName( )

getName( )

getLocator( )

toBeginning( )

nextService( )

hasNext( )

nextService( )
19 June 2001 

javax.tv.service.guide

ServiceDetails

(from navigation)

<<Interface>>

ProgramSchedule

retrieveCurrentProgramEvent()retrieveFutureProgramEvent()retrieveFutureProgramEvents()retrieveNextProgramEvent()retrieveProgramEvent()addListener()removeListener()

<<Interface>>

ContentR

getDimegetRatingetRatingetDispexceeds

<<In

ProgramEventDescription

getProgramEventDescription()

<<Interface>>

ProgramEvent

getStartTime()getEndTime()getDuration()getName()retrieveDescription()getRating()getService()retrieveComponents()

<<Interface>>

RatingD

getDimensgetNumbergetRatingL

(from 

<<Inte

SIM

(from 
19 June 2001 

Retrieving Current

Program Information

MyXlet : Xlet RequestListener : 

SIRequestor

OneService : 

Service

 : 

ServiceDetails

 : 

ProgramSchedule

getName( )

getServiceNumber( )

retrieveDetails(SIRequestor)

notifySuccess(SIRequest, SIElement[])

getProgramSchedule( )

addListener(SIChangeListener)

retrieveCurrentProgramEvent(SIRequestor)

notifySuccess(SIRequest, SIElement[])

getName( )

getStartTime( )

getEndTime( )

getRating( )
19 June 2001 

Conclusion

• DASE provides a very rich set of Java AP

part of the Procedural Application Environ

• The selected APIs are made to work toge• The Declarative and Procedural Applicati

may work together via the DOM APIs

• Content providers have a powerful enviro

to create compelling content 
Java TV 1.0 API Technical Overview

Jim VanLoo

Sun Microsystems 

James. Vanloo@sun.com

The objective of the javax.tv.* packages is to browse, select, and control broadcast content, both 

executable byte code and media streams. The package design requires certain broadcast protocol support, 

but abstracts the protocol so as to provide a single formalism for broadcast content and a single collection of 

interfaces to interact with such content. The scope of the technical overview is:

Execution Environment:

Java Virtual Machine

Broadcast Independent (Implicit) Packages (java.*)

Broadcast Specific Packages (javax.tv.* and javax.media.*)

Silent on User Interface Packages (java.awt.* and org.havi.ui.*)

Service Life Cycle:

Executable Content (javax.tv.xlet.*)

Media Content (javax.tv.service.*)

Service Metadata

Service Portals (javax.tv. {navigation,guide,transport})

Service Selection

Service

ServiceContext

ServiceComponents (with companion ServiceContentHandler)

Data Selection

Broadcast Protocol Data (javax.tv.carousel.*)

Internet Protocol Data (java.net.* and javax.tv.net.*)

Media Stream Control (javax.media.* and javax.media.protocol.*)

73
Session #, Session Title

The Java TV 1.0 API: Technical OverviewJon CourtneyJava TV Specification LeadSun Microsystems
Middle 2 Session #, Session Title

Purpose of This Presentation

Become familiar with the primary featuthat the Java TV API provides for creatcontent for interactive digital television

Beginning
Middle 3 Session #, Session Title

About the Speaker" Led the completion of the Java TV 1.0 

specification.

" Represented Sun and promoted Java T

API in television standards bodies in UEurope.

" Currently specification lead for J2ME 

Personal Profile.

Beginning
Middle 4 Session #, Session Title

Key Topics" Java TV Broadcast Environment" Application Life Cycle Model" Service Information API" Service Selection API" Broadcast Data APIs" Media Control

Beginning
Middle 5 Session #, Session Title

Environment

" Java Platform

Virtual MachineCore APIsUI APIsTV extension APIs
Middle 6 Session #, Session Title

Environment

" Broadcast Platform

Operating SystemTuner ControlDemux ControlConditional Access

Media PipelineService Information 

Database
Middle 7 Session #, Session Title

Broadcast Platform

Major Hardware Components
Middle 8 Session #, Session Title

Java TVArchitecture & APIs
Middle 9 Session #, Session Title

Java TV Components

Service

Information

Service

Selection

Broadcast

Data

Media

Control
Middle 10 Session #, Session Title

Basic services for TV applications

" Input/Output

Java.io

" Networking

java.net

" Graphics & UI

Java.awt

" System functions

java.lang, java.security, java.uti

Java Platform Features
Middle 11 Session #, Session Title

Java TV ArchitectureMajor API Elements" Application life cycle" Service Information" Service Selection" Broadcast Data" Media Control
Middle 12 Session #, Session Title

Java TV Architecture

Locators" A mechanism for referencing data and 

resources

" Locators are opaque references to

Broadcast file systemsPortions of service informationSources of audio and video contentetc.
Middle 13 Session #, Session Title

Java TV ArchitectureLocators" Handles to information and resources" Typically generated by the API" Created from / externalized to string for

LocatorFactory.create(String) -> LocatoLocator.toExternalForm() -> String
Middle 14 Session #, Session Title

Java TV ArchitectureSecurity & Resource Management" Policy is determined by network/platform" Policy enforced by receiver" Expressed using exceptions" Try & refuse model
Middle 15 Session #, Session Title

Java TV ArchitectureApplication Life Cycle Model
Middle 16 Session #, Session Title

Application Life CycleGoal: Define a model for TV applications" Learn from existing application models" Develop a model appropriate for TV
Middle 17 Session #, Session Title

Application Life Cycle ModelFeatures:" Ease of use for application developers" Model separate from:

Window system managementResource managementApplication management policy

" Minimal requirements on app managers
Middle 18 Session #, Session Title

Application Life Cycle Compone" Application Manager" Xlet" XletContext" Xlet State Machine
Middle 19 Session #, Session Title

Application Manager" Xlets can be destroyed at any time" Current state of Xlet will always be know" An Application Manager can change an

Xlet's state

" An Application Manager will know if an 

has changed state
Middle 20 Session #, Session Title

Application Life CycleFour application states:" Loaded

Code is loaded, initialized

" Paused

Application quiescent, minimal resource usage

" Active

Application is executing normally

" Destroyed

Application has released resources, terminated
Middle 21 Session #, Session Title

Application Life CycleXlet Interface" Implemented by the application" Methods to signal state transitions" Xlets managed by Application Manager" Similar to applet model w/o UI
Middle 22 Session #, Session Title

Application Life Cycle

Package javax.tv.xlet;public interface Xlet {

void initXlet(...);void pauseXlet();void startXlet();void destroyXlet(...);

}
Middle 23 Session #, Session Title

Application Life Cycle
Middle 24 Session #, Session Title

Application Life CycleXletContext" Provides property interface" Used by Xlet to signal state transitions 

application manager

" Xlet.initXlet(XletContext context);
Middle 25 Session #, Session Title

Application Life Cycle

package javax.tv.xlet;public interface XletContext {

Object getXletProperty(String);void notifyPaused();void resumeRequest();void notifyDestroyed();

}
Middle 26 Session #, Session Title

Java TV ArchitectureService Information API
Middle 27 Session #, Session Title

Service Information" What is Service Information?

Data in the broadcast streamProvides details about the available ser

" What is a Service?

A collection of content for displayAudio/Video/Applications/DataOften referred to as a "channel"
Middle 28 Session #, Session Title

Service Information" Data format is protocol independent" Accessible to applications via SI API" SI model is read-only database" Database populated from the broadcas
Middle 29 Session #, Session Title

Service Information API

Features" Protocol independent" Storage and delivery independent" Extensible for new SI types" Cached and non-cached access" Sync and async access" Service discovery
Middle 30 Session #, Session Title

Service Information API

Three "views" of service information:" Navigation package

Traversing through hierarchical SI data

" Guide package

EPG support

Program schedules, events, rating info

" Transport package

Exposes SI delivery mechanisms
Middle 31 Session #, Session Title

Service Information APIAsynchronous Retrieval" Database cannot cache all SI data" High latency in accessing data not in ca" Inconvenient for programs to block whil

waiting for data
Middle 32 Session #, Session Title

Service Information APIAsynchronous Retrieval" Asynchronous retrieval mechanism per

applications to queue requests and conexecution

" Asynchronous data access methods pr

with 'retrieve':

RetrieveProgramEvent(...)
Middle 33 Session #, Session Title

Service Information APIAsynchronous Retrieval" Interface SIRequestor implemented by 

applications to receive data

void notifySuccess(SIRetreivable[])void notifyFailure(...)
Middle 34 Session #, Session Title

Service Information APIAsynchronous Retrieval" Interface SIRetrievable extended by 

retrievable data types

BouquetNetworkProgramEventServiceDetailsEtc.
Middle 35 Session #, Session Title

Service Information API" SIRequest objects returned by asynchr

retrieval calls

Boolean cancel();

" Example:

SIRequest retrieveProgramEvent(LocatoSIRequestor);
Middle 36 Session #, Session Title

Service Information APIRequest model - summary" Objects wishing to receive service 

information asynchronously implementSIRequestor

" Data is returned as SIRetrievable" SIRequest objects returned to cancel th

request
Middle 37 Session #, Session Title

Service Information APISI Manager" Provides access to SI database" Event generator describing SI updates" Provides list of available services" SI filtering operations
Middle 38 Session #, Session Title

Service Information API

Package javax.tv.service.navigation;public class SIManager {

ServiceCollection 

createServiceCollection(ServiceFilter);

Service getService(Locator);Transport[] getTransports();SIRequest retrieveSIElement(Locator, SIReques

}
Middle 39 Session #, Session Title

Service Information API

Service API" Represents a source of content, aka

"channel"

" Selectable via service selection API" Persistent data: name/number, locator

Cached available synchronously"Installed services" for bootstrap

" Asynchronous access to service "detai
Middle 40 Session #, Session Title

Service Information APIServiceDetails" Service meta-data

Represents a specific instance of a servthe broadcastReports description, program schedule, Reports service components & types (eAudio, video, data)

" Extensible for new meta-data
Middle 41 Session #, Session Title

Java TV ArchitectureService Selection API
Middle 42 Session #, Session Title

Service SelectionFeatures" Abstracts "tuning" operation" Asynchronous operation" Conditional access results exposed" Support for multiple selection "contexts
Middle 43 Session #, Session Title

Service SelectionKey APIs" ServiceContext

Object used to select a serviceOften maps to a physical tuner on the d

" ServiceContentHandler

Responsible for the presentation of a seTypically related to a JMF Player
Middle 44 Session #, Session Title

Service SelectionServiceContext" Represents an environment for present

media and downloaded applications in service.

" Provides service selection operation

ServiceContext.select(Service);

" Reports currently selected service
Middle 45 Session #, Session Title

Service SelectionServiceContext" Management of multiple contexts" Access to content "handlers"" Signals current state via events for 

completion, redirection, failure
Middle 46 Session #, Session Title

Service SelectionService Context State Model" Not Presenting

PresentationTerminatedEvent

" Presentation Pending

After select operation, before completio
Middle 47 Session #, Session Title

Service SelectionServiceContext State Model" Presenting

NormalContentEvent: Requested contepresentedAlternativeContentEvent: C/A redirectio

" Destroyed

ServiceContextDestroyedEvent
Middle 48 Session #, Session Title

Service Context States

Not

Presenting

Destroyed

Presentation

Pending Presen

Select()

Stop()

(completion)

Select()

Destroy()

Destroy()

Destroy()

Stop()
Middle 49 Session #, Session Title

Java TV ArchitectureBroadcast Data APIs
Middle 50 Session #, Session Title

Broadcast DataFeatures" File style access to broadcast filesystem" Push style delivery for streams" DatagramSocket access to broadcast I
Middle 51 Session #, Session Title

Broadcast DataPackage javax.tv.carousel" Provides access to bounded data in 

hierarchical, cyclically transmitted broadfilesystem

DSMCC object carouselDSMCC data carouselATVEF UHTTP
Middle 52 Session #, Session Title

Broadcast DataPackage javax.tv.carousel" CarouselFile extends java.io.File

Represents broadcast filesFamiliar mechanisms from java.io packa

FileInputStreamRandomAccessFileFileReader
Middle 53 Session #, Session Title

Broadcast DataCarouselFile" Event notification of content changes

Interface CarouselFileListener

" Latency management

Instancing a CarouselFile notifies systeasynchronously cache file from broadca

" Referenced via locators or filenames

Broadcast filesystem is mapped into locname space
Middle 54 Session #, Session Title

Broadcast DataPushSourceStream" Represents source of streaming data" Acquired through JMF manager" Delivers data in non-flow-controlled ma

Client is notified when data arrives

" Subinterface throws exceptions for data 
Middle 55 Session #, Session Title

Broadcast DataPackage javax.tv.net" javax.tv.net.InterfaceMap permits acces

broadcast IP through conventional mechanisms

Dynamically maps locator to broadcast private local IP addressUnicast and multicast supportedAccess through familiar java.net mecha

DatagramSocket, MulticastSocket
Middle 56 Session #, Session Title

Java TV ArchitectureMedia Control APIs
Middle 57 Session #, Session Title

Media Control

" Java Media Framework manages pipeli" JMF Player wraps decoder, rendering" JMF DataSource wraps tuner & demux
Middle 58 Session #, Session Title

JMF Architecture

JMF API

DataSource Player

Application

Manager
Middle 59 Session #, Session Title

Media Control" Player

Renderer of streaming contentSupports one or more media typesLikely implemented in hardwareManages state and synchronization
Middle 60 Session #, Session Title

Media Control" Controller

Subinterface of PlayerProvides state change notificationManages state machine
Middle 61 Session #, Session Title

Media Control" DataSource

Abstracts the source of the media dataData is typedLocation of data referred to by an opaqureference
Middle 62 Session #, Session Title

Broadcast PipelineJMF Player and DataSource" Representation of network interface" Representation of rendering pipeline" Separation allows reuse of pipeline" Synchronization primitives

Media time exposed
Middle 63 Session #, Session Title

Broadcast PipelineJMF Player and DataSource" A/V control primitives

JMF Controls publishedRuntime extendibleMedia time control

" Resource management mechanisms

Events signal state transitions

" Small framework abstracts hardware
Middle 64 Session #, Session Title

JMF and Java TV" JMF mostly hidden to applications" DataSource & Player connected 

transparently

" When a service is presenting, the JMF 

Players can be obtained

SC.getServiceContentHandlers();

" Some standards define their own JMF 

controls
Middle 65 Session #, Session Title

Java TV ArchitectureAdditional APIs
Middle 66 Session #, Session Title

Graphics APIs" AlphaColor

Subclasses java.awt.ColorProvides a simple alpha blending color

" TVContainer

Provides Xlets with a root graphics cont
Middle 67 Session #, Session Title

Timer API" Provides support for timed events" Allows applications to be called after a 

particular time has elapsed

" Similar to PersonalJava pTimer API
Middle 68 Session #, Session Title

Additional Information" Java TV product web page

java.sun.com/products/javatv
Session #, Session Title
Middle 70 Session #, Session Title
ATSC Digital Television 

MPEG, PSIP and Data Broadcast

Rich Chernock

IBM Research Watson 

Research Center Hawthorne, 

NY 

chernock@raleigh.ibm.com

This presentation will give a broad overview of the ATSC system layers that DASE builds upon and assumes to 

be present. While not an in-depth examination of these layers, the intent is to give the audience an idea of the 

framework that they can count on and must use. The topics to be covered are: MPEG-2 Systems, PSIP and Data 

Broadcast.

MPEG-2 Systems: The base "plumbing" layer that ATSC utilizes for the transport of all broadcast data. 

MPEG-2 systems provides the multiplexing and encapsulation structures to carry data for DASE applications, as well 

as "metadata" (PSI) necessary to unwrap the different broadcast components.

PSIP: Program and System Information Protocol, which is used in ATSC systems to allow receivers to discover 

what components are in the broadcast, link to the resources and provide program guide functionality to the viewer.

Data Broadcast: The T3-S 13 data broadcast standard (Al90) which specifies how to encapsulate data for 

broadcast on an A TSC system, as well as the mechanisms for announcement (figure out what will be broadcast) and 

signaling (locate and bind the resources for a data service).

111
ATSC Digital Television:

MPEG, PSIP and Data Broadca

Rich Chernock

IBM Research

chernock@raleigh.ibm.com

With thanks to:

Pete Schirling, IBM

Art Allison, NAB

Regis Crinon, Intel

Michael Isnardi, Sarnoff
Environment

The Old Days The Old Days: Television involves wiggling voltages in the right way 

: Television involves wiggling voltages in the right way 

right times so the receiver can recreate the pictures right times so the receiver can recreate the pictures

The New Paradigm: Television involves transmitting database inform

: Television involves transmitting database inform

parameters to allow the pictures to be calculated. parameters to allow the pictures to be calculated.

Observations Observations:

This is NOT a computer network This is NOT a computer networkA TV is not expected to behave like a computer A TV is not expected to behave like a computerGoing black is Going black is NOT an option an option

Assets not available locally or in the broadcast Assets not available locally or in the broadcast

don’t exist don’t exist

RiGjBk 

of D

of D
MPEG-2 Systems Overview

Pete Schirling

Senior Consulting EngineerIBM ResearchDigital Media Standards and Commercializat

River Road MS Essex Jct, VT 0Phone -+1 802 Fax -+1 802 e-mail -schirlin
MPEG-2 Systems MPEG-2 Systems 

Everything you didn't want to know but ne

to in order to keep your job !!
MPEG-2 Transport Stream

Multiple programsAssociated program information

PSI (Program specific information)other information program or non-program 

Private or public information

Conditional accessNetwork or application specific

enabled as a universal carrier of real-time non-real time information
MPEG 2 Data Stream Definitio

Xh Xh Xh Xh Xh

Transport Packet

Contains data from 1 program / 1 elementary data type

Fixed payload length (184 Bytes)

payload payload payload payload pay

sync(8) PID Co

C

Adap hdr(2) error bit(1) PES start(1) Priority (1) (13) Scrambling cntl_fld(2)

01000111

4 Bytes

PID Assignments

0000- Program Table0001- Conditional Access

Scrambling Cntl

00 - not scrambled01- user defined10 - user defined11 - user defined

Adaptation Cntl

00 -reserved01- no A_F, Payload10 - A_F, no payload11 - A_F , payload

incr opresepaylo

0002-000F Reserved0010-1FFE User defined1FFF reserved
MPEG-2 Program Specific Informatio

(PSI)

Program Association Table

Links the MPEG-2 program_number with the PID carryinTS_program_map_section

Conditional Access Table

Carries CA_descriptors that point to the PID carrying the access vendor’s Entitlement Management Message (EMM

Program Map Table

Formed by the aggregation of all TS_program_map_sectiocontained in an MPEG-2 Transport StreamEach MPEG-2 Program’s TS_Program_map_section cont“Program Definition”The “Program Definition” specifies the Program Elements descriptors associated with the MPEG-2 Program

Transport Stream Description Table

Carries descriptors scoped to the entire transport stream
MPEG-2 as a clocked multiplex

delivery is based on a constant delay modecoder system clock is carried in the strdecoder resource management is based decoder synchronization is based on STC
CBR vs VBR CBR vs VBR

CBR - Constant bit rate

non-variant byte stream

VBR - Variable bit rate

piecewise constant bitrateused in statistical multiplexing applicat
Audio/Video Synchronization udio/Video Synchronization

encoder decoder

buffer buffer transport storage

video

audio

video

audio

system encode system decode

STC STC

constant total delay

PTS

PTS PTS

PTS

STC = System Time Clock
Transport Demultiplexing Transport Demultiplexing 

example example

MPEG-2 Transport Stream

containing one or multiple programs

Data Link Data 

link

specific

decoder

Transport Stream

demultiplex and 

decode

Clock

control

Video

Decoder

Audio

Decoder

Decoded

Video

Decoded

Audio
Clock Recovery Clock Recovery

PCR

PCR STC

Difference

ClockControl
Buffer Management Buffer Management

STC runs too fast - 

caused by early byte arrivals decoder runs too fastcauses buffer underflow

STC runs too slow -

caused by delayed byte arrivalsdecoder runs to slowcauses buffer overflow

results in FRAME SLIPPING
Program and System Information Protoc

Terrestrial Broadcasting and Cable

P S I P

Art Allison

Director, Advanced Engineering 

Science and Technology
Why do we have PSIP? 

&

What is PSIP?
Pick your Pick your channel channel

Legacy Syst Legacy System

47 48 49
DTV System

Pick your Pick your Hand

47 48 
Requirements Requirements

• Preserve channel number branding• Support direct access to any channel

• Harmonized between terrestrial broadand cable TV• Compatible with printed program guides
Requirements Requirements

• Support a variety of user-friendly navigat

paradigms

Support grouping of digital and analog services

Extensible to data broadcasting and other services
PSIP Defined PSIP Defined

• PSIP = Program and System Informati

Protocol

• Defined in ATSC Standard A/65A and 

Amendment 1 to A/65A

• Combines and Compacts A/55 and A/56 • Must be transmitted by ATSC terrestria

broadcasters in their DTV Transport Str
What PSIP provides What PSIP provides

• Leverages existing broadcaster brand n

– Maintain your channel identity

• Enables faster tuning• Supports V-Chip and conditional acce• Also Provides an announcement servic

– Simple enough to go in every receiver– Extensible for higher end products– Small change in tuning paradigm for con– Compatible with printed media
Complementary Functions Complementary Functions

Bind and Announce Bind and Announce

• Main Table for current conditions

– Contains the Transport Stream Linkages– Supports Tuning of the Programs Now

• One Main Table that describes LATER

– Contains Future Event Announcements

• (and in-progress events)

– Enables Basic Electronic Program Guide

• Supporting Tables
Scope of PSIP

Ch. 2 Ch. 31 C

WXYZ WXYZ-DT W

Analog digital 

PSIP Data Must describe 

DTV programm

May describe associated

analog channel’sprogramming.

May describe

another DTVchannel’sprogramming.

(6 MHz) (6 MHz) 
PSIP Generation/Insertion

NTSC PLANT

[24] Etc.

NTSCINPUT

DATA

EXTRACTOR

[31]

DATA

INSERTER

[33]

DATA 

BRIDGE

[32]

PSIP, UPI

and PSI

GENERAT

M

DATA 

SERVER

[88]

M

MU

[8

VIDEO 

ENCODER

[79]

AUDIO 

ENCODER

[80]

DATA 

EXTRACTOR 

[77]

DIGITAL

PLANT

[70] Etc.

WAN

[89]

DECODERS

[52-53] Etc.

DEMUX

[50][57]

M

DIGITALINPUT

Copyright © 1998 by the Advanced Television Systems Committee. Annotations by Sarnoff corporation..

TOP-DOWN DATA PLANE

(taken from ATSC Implementation

Subcommittee’s “Top Down”

Report)

Management and Control

Plane Interface

Ensures consi

between PAT/P

PSIP data
Tuning Example - PSIP

PID 

0x1FFB

Look Up 

PID’s

Virtual ChannelTable

MultiProgram

Transport

Stream

Filter PID’s for 

Elementary Streams

PID # TypePID-V VideoPID-P PCR PID-A AudioPID-D Data

“Tune to Program 12-3”

Create 

Program 

Guide
PSIP Tables PSIP Tables

STT System Time Table - provides time

MGT Master Guide Table - provides version, size and PID’s o

other tables (except STT)

VCT Virtual Channel Table - provides attributes for all virtua

channels in this Transport Stream

RRT Rating Region Table - provides rating information for m

geographic regions

EIT Event Information Table - provides information for eve

the virtual channels

ETT Extended Text Table - provides detailed descriptions of 

channels and events

DCCT Directed Channel Change Table

DCCST Directed Channel Change Selection Code Table
What’s Required for Transmissio

Table Required for Broadcast? Required for Cable?

STT

MGT

VCT

RRT

EIT

ETT

✔✔

✔ (TVCT)

✔✔

✔

✔ (EIT-0, -1, -2, -3)

(all others optional

)

optional

✔ (CVCT)

✔

optionaloptional

Note: For out-of-band sign

in cable, refer to SCTE-DV
Table Hierarchy

Base PID

0x1FFB

STT

MGT

RRT

VCT

Chan A

Chan B

Chan Z

•••

ETT-V

EIT-0

Event(s)

•••ETT-0

Event(s)Event(s)

EIT-1

Event(s)

•••ETT-1

Event(s)Event(s)

EIT-2

Event(s)

•••ETT-2

Event(s)Event(s)

EIT

Even

•••E

EvenEven

PID-EIT0

PID-ETT0

PID-EIT1

PID-ETT1

PID-EIT2

PID-ETT2

PID-E

PID-ETTV 

• STT, RRT, MGT and VCT are carried in Tra

Packets with Base PID

• MGT contains PID values for EIT and ETT 

Packets

• EIT’s carry event information for 3-hour tim
Maximum Cycle Times

MGT

TVCT

EIT-0

STT

RRT

0123456
Master Guide Table (MGT) Master Guide Table (MGT)

• Lists key information about all other P

tables (except STT):

– version numbers– table sizes– PID’s

• Allows simpler decoder designs since 

change in PSIP status is flagged in this table.

• Only the base PID (0x1FFB) needs to 

monitored to detect change in PSIP sta
MGT Example: Time T

0

MGT

tables_defined = 6; version = 8

0x00000x01000x01010x01020x01030x0301

Type

TVCT

(current_next = 1)

EIT-0EIT-1EIT-2EIT-3

RRT

(rating_region = 1)

Name

0x1FFB0x1AA00x1AA10x1AA20x1AA30x1FFB

PID

Note: Underlined values are variable from station to stati

222110

Version

B
Virtual Channel Table (VCT

Virtual Channel Table (VCT

• Contains list of channels in the Transport St• May also include broadcaster’s analog chan

and digital channels in other Transport Strea

• TVCT = Terrestrial VCT; CVCT = Cable V• Key info in VCT:

– short name– major and minor channel numbers– Transport Stream ID (TSID) and program numb– source ID, service type, access controlled and h

flags

– Service Location Descriptor: contains list of PID

elementary streams
Major-Minor Channel Number Exam

RF Ch. 2

RF Ch. 31

“2-0”“2-1”

R

WXYZ WXYZ-DT W

analog digital 

An existing analog broadcaster with

a second digital channel. Branding

is preserved. The DTV RF channel

number is not needed at all!

A di

bro

(no ana
Program Number

0x00B3

Program Number0x00B3

PAT and PMT

• The Program Association Table (PAT) associates M

Program Numbers with Program Map Table (PM

• The PMT associates program elements with PID’s• These tables are required for MPEG-2 compliance

Program Association Table (PAT)table_id = 0x00•••transport_stream_id = 0x0AA1•••

Program Association Table (PAT)table_id = 0x00•••transport_stream_id = 0x0AA1•••

Program Number PMT PID0x00F1 0x01000x00C2 0x04400x00B3 0x0301

Program Number PMT PID0x00F1 0x01000x00C2 0x04400x00B3 0x0301

Example PAT

Stream Type PPCR 0xVideo 0xAudio 0x

Stream Type PIDPCR 0xVideo 0xAudio 0x

Example PMT 

PID 0x0301
The Program Number Myth

• MPEG-2 Program Numbers are not related to Major-

Channel Numbers!

• MPEG-2 Program Numbers are hidden from the view

serve to link MPEG-2 data structures (PAT and PMT

• Major-Minor channels numbers are what viewers “tu

Terrestrial Virtual Channel Table (TVCT) Terrestrial Virtual Channel Table (TVCT)

Major-Minor Number Program Number Channel TSID Descripto12-1 0x00F1 0x0AA1 Service Lo12-2 0x00C2 0x0AA1 Service Lo12-3 0x00B3 0x0AA1 Service Lo

Major-Minor Number Program Number Channel TSID Descriptor12-1 0x00F1 0x0AA1 Service Lo12-2 0x00C2 0x0AA1 Service Lo12-3 0x00B3 0x0AA1 Service Lo

What the viewer

“tunes to”

Hidden from the

viewer

Tells the 

where to f
TVCT Example

TVCT

number_channels_in_section = 5; TSID = 0x0AA1

1212121212

Major

Num.

015

1231

Minor

Num.

NBZ

NBZ-D

NBZ-S

NBZ-M

NBZ-H

Short

Name

205.25620.31

Carrier

Freq (MHz)

0x0AA00x0AA10x0AA10x0AA10x0AA1

Channel

TSID

Adapted from A/65

620.31620.31620.31

0xFFFF

0x0F21

0x00B2

0x0CC70x0CD0

Program

Number

analog

digitaldigitaldigitaldigital

Service

Type

2021385414

Sourc

ID
Electronic Program Guides

Chan Name 6:00 PM 6:30 PM 7:00 PM 7:30 PM 8:00 PM 

CBZ City Life Travel Mo

W

6-06-1 CBZ City Life Travel6-2 CBZ

LCL

Movie: Secret Agent

6-3 Local News Airport Info

Mo

Wild 

• Interactive and Useful

- Event, Channel and Purchase Information- Automatic Recording

* With Future Extensions, can enable Thematic Browsin

Sorting- DCC has categories and enables automatic re-to retain VC to PID consistency ( RFP is out now)

Tune 6-1 

Wild 

HD P

on 

Adapted from slide 
Event Information Tables Event Information Tables

• Each EIT spans 3 hours• Start time for each EIT is constrained to be 

the following UTC times:

– 0:00 (midnight), 3:00, 6:00, 9:00– 12:00 (noon), 15:00, 18:00, 21:00

• EIT-0 represents the ‘current’ 3 hours of 

programming

• For terrestrial PSIP, first 4 EIT’s (EIT-0, -1

-3), representing 9 to 12 hours, are required

• Maximum number of EIT’s = 128 (16 days)
EIT Example

EIT-0

source_id = 22

num_events_in _section = 3

515253

Event

ID

12:3014:30

Local

Start

Time

720036009000

Length

(seconds)

Adapted from A/65

15:30

01

(this PTC)

00

(no ETM)

01

(this PTC)

ETM

Location

Soccer Live

Golf Report

Car Racing

Title
PSIP and Data Services (A/90

PSIP and Data Services (A/90

• Announcement via Extension to PSIP

– Data Event Table (DET) - based on EIT

• For Separate Data Services• Points to the VCT• VCT Points to new Structure 

• Announcement via EIT

– Data Information may be in EITs

• For Related Data Services

• Binding via new Table Structures

– Service Description Framework
Relevant PSIP Documents Relevant PSIP Documents

• PSIP Standard (A/65A)• PSIP Amendment 1 to A/65A (Directed Channel C

– ATSC T3 re-ballot just completed

• Conditional Access System for Terrestrial Broadca

(A/70)

– Defines ATSC_CA_descriptor for VCT and EIT

• “U.S. Region Rating Table (RRT) and Content Adv

Descriptor for Transport of Content Advisory InforUsing ATSC A/65 Program and System InformatioProtocol (PSIP)”, September 1998 (EIA-766)

– Used for rating and content advisory in the U.S.
THE ATSC

DATA BROADCAST SPECIFICATION:

PRACTICAL IMPLEMENTATION 

CONSIDERATIONS

Regis J. Crinon, Ph.D.

regis.j.crinon@intel.com

Intel Corporation

JF3-206

2111 N.E. 25th Avenue 

Hillsboro OR 97124
OUTLINE

1. DTV Data Services: Generalitie2. The A/90 specification

• composition• scope

3. Data Service schedules announ

• types of services• extensions to PSIP

4. Protocols 5. Service Description Framework6. Data Service profiles and level7. Summary and conclusion
ATSC Transport Stream carrying mu

• AC-3 audio streams (A/53)• MPEG-2 video streams (A/52)• Service Information (A/65 + MPEG-• data elementary streams (A/90)

DTV = Audio + Video + Data
As opposed to NTSC VBI-based Data S

DTV Data Services are an integral part 

Broadcast signal:• Data share the same multiplex with vid• Same fundamental MPEG-2 acquisition 

are used to acquire data, video and audi

• Data Services may be announced in a Pr

Guide like Video/Audio programming

IMPACT ON 

DTV MARKETABILITY
satellite

downlink

data 

gateway

data server 2

dataserver 1 

A/VA/V/DA/DD

demod + 

data decode

Otherappliances

Mux + modulation

data encode

audioencode

videoencode
WHAT DOES ATSC A/90 SPEC

Data ServicesSchedule

Data DeliModels

Protocols

MPEG-2 systems tools

AppliSigna

A/90
SCOPE OF ATSC A/90

Examples of what it can be used for 

• Delivery of declarative data, Java code

• Delivery of software, images, graphics• MPEG-4 or H.263 video streams (data piping)• MPEG-4 audio streams (data piping)• Carousel of MPEG-2 video files (.mpg files) • Carousel of MP3 audio files 

What it cannot be used for :• Audio elementary streams of type 0x81• Video elementary streams of type 0x02
ANNOUNCEMENTS OF 

DATA SERVICE SCHEDULES

• One data service per virtual ch• A/90 has invented DET-k’s

source _idsource _id

RRTSTTMGT

VCT

B-PID

EIT-0 EI

source _id

for channel w:for channel x:

source _id

source _i

source _i

PID-K PID-L PID-M PID-N

source_id

source_id

source_id

source_id

DET-1 DET-0

for channel y:source _id

for channel z:

source _id
PACKETIZATION, ERROR PROTEC

AND PROTOCOLS

MPEG-2 Transport Stream

Non-flow

controlled

LLC/

SNAP

PE

pack

SDF

addressable

sections

MPEG-2

sections

DSM-CC 

sections

checksum

CRC32

checksum

CRC32

checksum

CRC32

MPEG-2

PTS

data

carousel

DSM-CCdownload

MPEG-

IP 

LL

SN
Periodic re-transmission of the same dat

content providers to cope with viewers csurfing.... 

DSM-CC DATA CAROUSEL

Channel 12.3

Channel 1

statistics
Periodic re-transmission of the same dat

content providers to cope with loss of daExample: Software download.

DSM-CC DATA CAROUSEL
ADDRESSABLE SECTIONS CARR

IP DATAGRAMS

ATVEF enhancementsto A/V programming

Web coInterne(dataca
SYNCHRONIZED DATA

factoid

Data is synchronized with audio/video c
APPLICATION SIGNALING

Video elementary streaAudio elementary streaData elementary streaData elementary streaData elementary strea

Data Servi

SDF data

Network Se

ATSC

Virtual Channel

SDF data for discovery and binding of components used by a receiver applicat
REFERENCE TO DATA WITHI

SAME VIRTUAL CHANN

App1App2

Data Service Table

ATSC multiplex
DATA SERVICES FOR

DUAL-TUNER RECEIVERS

ATSC Multiplex1 ATSC 
REFERENCE TO DATA IN AN

VIRTUAL CHANNEL

Network Resour

Tuner 1

Tuner 2

Resource 1Resource 2

App1

DST
DATA SERVICES FOR

RECEIVERS FEATURING 

A BROADBAND CONNECTION

ATSC multiplex

Intern

Broadband co
REFERENCE TO DATA AT 

A REMOTE WEB SITE

NetworkResourceTableResource 1Resource 2

App1

DST
APPLICATION SIGNALING

SDF data is part of the data service 

so content providers must provision (and for its transmissionContent provider may select how often ahow big SDF information can be. 

Trade-off between:

• tune-ability to data services • latency to get access to data
DATA SERVICE

PROFILES AND LEVELS

• Signaled in a descriptor carried in th

EIT-k’s or DET-k’s

• Profiles determine the maximum bitr

that a data service consumes

• Levels are linked to receiver memory 

throughput requirements for synchro

services
FOUR DATA SERVICE PROFIL

G1G2G3A1

Guaranteed bandwidth up to 3Guaranteed bandwidth up to 3Guaranteed bandwidth up to 1

Opportunistic up to 19.2 Mbp

(NTSC VBI-based Data Services: 180 kbi
DATA SERVICE PROFILES

Two classes of profiles:• Guaranteed bandwidth 

Specifies maximum bandwidth that h

been provisioned for transmission oservice. 

• Opportunistic bandwidth

Bandwidth assigned to transmission 

data service is variable in time, dep

instantaneous availability (bandwidt

by audio and video)
GUARANTEED BANDWIDT

19.2Mbps

2 G1

G2

Bandwidth for A/V
OPPORTUNISTIC BANDWIDTH

VIDEO AND/OR AUDIO

19.2 Mb

DATA
USE OF DATA SERVICE PROFI

Data Service profiles enable br

of total bandwidth reserved for data in an ATSC multiplex:G3 = 5 G2 = 50 G1 = 4 G2 + 10 G1 = ...5.76 Mbps = G2 + 5 G1

Data Service profiles specify ta

receiver capability

At the head-end

At the receiver
FOUR DATA SERVICE LEVELS

Level1Level4

level16Level64

DEBSn = 120120 bytes DEBSn = 480480 bytesDEBSn = 1921920 bytes

DEBSn = 7687680 bytes

Max throughput at level 1 = 172.8 Mb
SUMMARY

• Rich set of protocols and functionalit

allow progressive deployment of incremore sophisticated services

• A/90 specifies delivery data for broadc

pseudo-interactive services but at the slays the ground for interactive services

• A/90 was input to SCTE for review (DV• A/90 has a high level of compatibility w

1) Data Carousel2) Synchronized protocol 3) Carriage of IP datagrams

• Led to 3 MPEG Systems amendments
THE ATSC T3/S13 DATA 

BROADCAST SPECIALIST GROU

The Data Broadcast Standard available on the ATSC Web Sithttp://www.atsc.org/Standards/A90/A90A companion implementation guavailable in the form of a recompracticeWorking on a IP Multicast spec
THE ATSC IS / DIWG

Data Implementation Working Gr

DIWG report is available on the Web Site:http://www.atsc.org/Standards/IS_151.pd
Everything you ever wanted to know a

Data Broadcast

• Data Broadcasting: Understandin

the ATSC Data Broadcast Stand

– R. Chernock, R. Crinon, M. Dolan, J. – McGraw Hill, 2001
Application Reference Model 

Michael A. Dolan

Industry Consultant, 

miked@tbt.com 

ATSC is working on data broadcasting transport issues (A/90) as well as data-specific application

environments (DASE). However, when it comes time to implement a receiver, there is a gap between them

where normative bindings and behavior needs definition. This is the Application Reference Model (ARM).

It covers a uniform naming system, data model characterization, and an application state model. This

coverage addresses such things as defining MPEG descriptors to provide the proper name bindings, and

provide guidance on state transitions based on events in the transport signaling. Also included are data

models such as files, streams, and IP packets. In summary, this links together all the basic constructs in the

ATSC data transport to ATSC-DASE, and is general enough to be used by other application environments

if needed. 

149
19-June-01 © 2001 Michael A Dolan

Michael A. Dolan

19-June-2001

NIST/ATSC Symposium: End-to-

Data Services, Interoperability an

Applications

Data Application Referenc

Model
19-June-01 © 2001 Michael A Dolan

Overview

• Provide the glue between A/90 transpo

and DASE application environment

• Application model builds on several A

standards

• Main areas of focus are:

– Naming system– Data Model Characterization

• Application State Model
19-June-01 © 2001 Michael A Dolan

Warning & Disclaimer

• This presentation discusses ATSC wor

process, and therefore cannot be relied for product development or even excepfinal endorsement by the ATSC. This informative presentation about current thinking of the technical experts on a trelevant to this audience.
19-June-01 © 2001 Michael A Dolan

ATSC Standards Relationsh

– A/53 (Core ATSC video & audio)– A/70 (CA)– A/65 (PSIP)– A/90 (Data Broadcast Framework)– S13 Work in Process

• IP Multicast (IPM)• Triggers• Transport Stream File System (TSFS)
19-June-01 © 2001 Michael A Dolan

A/65

A/53

A/90

Triggers IPM

DASE

TSFS

ARM

A/70

ATSC Standards Relationsh
19-June-01 © 2001 Michael A Dolan

Data Models

• Modules• Files• Streams• IP Packets• Triggers
19-June-01 © 2001 Michael A Dolan

Module Data Model

• Similar to files, but generally only use

– Receiver firmware upgrades– Synchronized downloads– Limited naming scenarios– Other “simple” scenarios

• (no mapping to DASE data model)
19-June-01 © 2001 Michael A Dolan

File Data Model

• Bounded sequence of bytes• Just like a computer file system• Hierarchical namespace with directori• Carried in DSMCC modules• Defined by T3/S13 in TSFS Standard

– (Will likely be Object Carousel)

• Maps to DASE resource
19-June-01 © 2001 Michael A Dolan

Stream Data Model

• Unbounded sequence of bytes• Like a UNIX pipe or IP/TCP connecti• Carried in either:

– DSMCC Asynchronous Download– Data Piping

• Defined by application• Maps to DASE JMF built-in data sour
19-June-01 © 2001 Michael A Dolan

IP Packet Data Model

• Internet Protocol Packets• Primarily Multicast only• Carried in DSMCC Addressable Secti• Defined in T3/S13 IP Multicast Standa• Maps to DASE datagram socket
19-June-01 © 2001 Michael A Dolan

Trigger Data Model

• Event delivery to receiver• Supports both targets:

– Synchronized Module– Application Event

• Carried in DSMCC Download• Defined by T3/S13 Trigger Standard• Application Event maps to DASE DO

Events
19-June-01 © 2001 Michael A Dolan

Naming System

• Need to provide names for the transport reso• Each data model is supported• tv: URI scheme used for current video/audio

– RFC 2838

• lid: URI scheme used for all other resources

– SMPTE work in process

• Signaling is via descriptors in the DST, as w

DII (for modules)
19-June-01 © 2001 Michael A Dolan

State Model

• Needed to provide basic transport laye

environment management

• Based on A/53, A/65 and A/90 signali• Input events are existing transport sign• States are abstract
19-June-01 © 2001 Michael A Dolan

State Model Events

• DST contains a new application• DST omits a previous application• PMT omits the DST• PMT omits the Program Element that 

contains the “boot” resource

• Channel Change
19-June-01 © 2001 Michael A Dolan

State Transition Diagram

Unloaded Loading

Suspended Running

AppNew

(loading c

AppGone DSTGone TapGone ChanChange

AppGone DSTGone TapGone ChanChange

AppNew

(Resources Needed)
19-June-01 © 2001 Michael A Dolan

Receiver Block Diagram

Platform

Services

IO,

Memory

MPEG2 video decAC3 audio dec

MPEG PSI dec

ATSC PSIP dec

ATSC SDF dec

TBnTBnTBnTBnTBn

BnMBnBnBsysBn

TBnTBn SBn

Bn

TBn SBn

EBnDEBn

SBn

Display

Model

Async. data

Synchronous data

Sync’ed data

STT, RRT, MGT, VCT

EIT-k’s, DET-k’s, ETT-k, LTST

TBnTBn Bsys

PAT

PMT

DST, NRT

Audiostream_type 0x81

Videostream_type 0x02

App

BufferModel

Application

Environment.

User

Input

Audio

Out

Backchannel

State

Model
19-June-01 © 2001 Michael A Dolan

A/90 Extensions & Constrai

• New Information• Announcement• Signaling• Encapsulations
19-June-01 © 2001 Michael A Dolan

New Information

• appID = UUID• Compatibility Descriptor• Identifiers (lid:)• Content Type• Broadcaster Permissions
19-June-01 © 2001 Michael A Dolan

Compatibility Descriptor

• Organization (OUI)• Capability• Profile• Level
19-June-01 © 2001 Michael A Dolan

Content Type

• “MIME” Type• More clearly defines content of:

– Modules– Files– Streams– Triggers
19-June-01 © 2001 Michael A Dolan

Broadcaster Permissions

• High level broadcaster control• Permits denial of application functiona• Usable by data service author, too• Examples:

– Prevent channel change (by application, n

user)

– Prevent display usage (which could obsc

video)
19-June-01 © 2001 Michael A Dolan

Announcement

• Advance notification of service inform• Used to make EPG and scheduling 

decisions by both receiver and viewer

• Placed in EIT and optionally, DET• Compatibility Descriptor primarily, bu

– Title, start time, and duration, if they are 
19-June-01 © 2001 Michael A Dolan

Signaling

• Real time information about the transp

resources

• Includes

– appID– Compatibility Descriptor– Identifiers– Content Types– Broadcaster Permissions
19-June-01 © 2001 Michael A Dolan

Encapsulations

• (Asynchronous only for now)• Asynchronous non-flow controlled scenario 

DSM-CC Download protocol encapsulated DSM-CC sections

• Non-streaming Synchronized Download pro

encapsulated in DSM-CC sections

• Asynchronous IP datagrams in Addressable 

Sections

• Proprietary Data Piping
19-June-01 © 2001 Michael A Dolan

Summary

• Application Reference Model• Glues A/90 with DASE• Extends/Constrains A/90• Provides Data and State Models• Provides uniform resource naming• Needed for interoperable implementat
19-June-01 © 2001 Michael A Dolan

Author Information

Michael A Dolan

miked@tbt.com

T3/S18 Chair

Thanks to DIRECTV for support in the 

general field and work with ATSC in particular.
DASE Security

Taylor Kidd

OpenTV 

tkidd@opentv.com

As embedded processors and digital communications come to dominate the world that surrounds us, 

computer and digital security plays an increasingly important role. Today, television is transitioning into

this digital world as various private and public organizations throughout the world struggle to define and 

implement the infrastructure needed to bring digital TV to every household. Along with the many

remarkable advantages of using digital information (e.g. almost zero information loss, increased noise 

tolerance, accompanying programs), there are also risks due to the complexity and remarkable malleability 

of digital data. As such these drafting organizations, including the A TSC (Advanced Television Systems 

Committee) T3/S 17 Specialist Group -sometimes referred to as the DASE Specialist Group -are working to 

include elements of digital security in their specifications.

This presentation briefly outlines and introduces digital security, covering threats, services and

mechanisms. After discussing the security approach of some of the different DTV (Digital TV)

specifications being developed around the world, it focuses in on the security approach of the DASE 

(Digital TV Application Software Environment) Level 1 draft specification. Subsequently, the presentation 

concludes with some of the scenarios and approaches under consideration in DASE Level 2 security.

165
DASE Security

Taylor Kidd (OpenTV)

tkidd@opentv.com

19 June 2001
DASE 2001 Symposium

Outline

• Objective of Security• DASE L1 Security• DASE L1+• Architecture
DASE 2001 Symposium

Objective of Security

Protect and Assure

– Confidentiality– Integrity– Availability

Against Threats

– Competitors– Hackers– Thieves– Etc.
DASE 2001 Symposium

Security Services

• Peer Entity Authentication• Access Control• Data Integrity• Data Confidentiality• Non-repudiation
DASE 2001 Symposium

Peer Entity Authentication

Determine identity of participants

– Unilateral Authentication– Mutual Authentication

E.g. 

– Bad Guy replaces his own bogus “Instant Winn

answer file for the Gilligan Game Show before signal is broadcast.

– B. Guy substitutes in a bogus update file contain

1-800 phone numbers for USA TV-banking befthey’re broadcast.

– B. Guy sends a fake transaction to Jake’s bank v

return channel.
DASE 2001 Symposium

Access Control

Regulate User Access to Resources

– Used with other services– Log user activities

E.g. 

– A Bad© Cola ad application attempts to access 

proprietary statistical data saved by Coke ads.

– A Bad© Cola ad application attempts to access 

proprietary code and data associated with a Pepad. 

– A Bad© Store ad application attempts to access 

home email address saved on the receiver to selspammers.
DASE 2001 Symposium

Data Integrity

Insures Data Quality

– Practically means data sent is data received– Not Peer Entity Authentication

E.g. 

– B. Guy modifies the “Instant Winner” answers f

Gilligan Game Show before the signal is broadc

– B. Guy modifies the file containing 1-800 phon

numbers for USA TV-banking before they’re br

– B. Guy modifies a transfer transaction to Jake’s 

sent via the return channel.
DASE 2001 Symposium

Data Confidentiality

Protects against unauthorized access to 

information

E.g. 

– B. Guy views a pay-per-view Boxing wit

paying.

– B. Guy views the “Instant Winner” answ

broadcast for the Gilligan Game Show. 

– B. Guy monitors Jake’s credit card numb

during a TV-Purchases, Inc., transaction the return channel.
DASE 2001 Symposium

Non-repudiation

Protection from denialE.g. 

– After an e-commerce transaction with TV

Purchases, Inc., B. Guy denies the transatook place.
DASE 2001 Symposium

DASE L1 Services

Has

– Access Control

• Limited usefulness because there is no peer e

authentication

Doesn’t have

– Peer Entity Authentication– Data Integrity– Non-repudiation 

• not relevant w/o return channel

– Data Confidentiality
DASE 2001 Symposium

DASE L2 Services (potentia

• Peer Entity Authentication• Data Integrity• Access Control• Probably handled in part or in whole b

outside entities

– Data Confidentiality (e.g. encryption)– Non-repudiation (e.g. transaction record)
DASE 2001 Symposium

Broadcast

DASE receiver

Broadcast Environment

application/

dase-permission

application/

dase-permission

Application

Procedural 

Engine

Decl

En

Security Mana

User/Receiver 

Policy

User/Receiver 

Policy

Broadcaster 

Policy

Broadcaster 

Policy

code

code c

Return Channel
DASE 2001 Symposium

Security Architecture

• Procedural Engine

– Code in Java– Uses Java 2 Security 

Model

• Security Manager• Policy Object• Permission Objects

– Well defined and tested

• Declarative Eng

– Code in

• XDML• ECMAScript

– Policies

• application/da

permission po

• Broadcaster pe

policy

• Viewer/receiv• Legacy applic

– Security

• Implementatio

Dependent
DASE 2001 Symposium

application/dase-permissio

• XML Application• List of “Request” objects identifying g• Bundled with TV program

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE Permission PUBLIC "-//ATSC//DTD DASE Permission <Permission>

<Request Name="File" Target="/com/tv/info.dat" Actions="<Request Name="ServiceSelection" Target="*" Actions="*"/

</Permission>
DASE 2001 Symposium

application/dase-permission: 

Operation or Feature Designation Request NaCookie Create, Delete, or Modify grantable CookieEvent Attribute Create or Modify grantable RuntimeCodFunction.[[constructor]] grantable RuntimeCodGlobal.eval grantable RuntimeCodHTMLDocument.write grantable RuntimeCodHTMLDocument.writeln grantable RuntimeCodScript Element Create or Modify grantable RuntimeCodWindow.setTimeout grantable DelayedEvaXlet Instantiation grantable Xlet
DASE 2001 Symposium

application/dase-permission: 

Permission Class Designation Rejava.awt.AWTPermission denied nonjava.io.FilePermission grantable Filejava.lang.ReflectPermission denied nonjava.lang.RuntimePermission denied nonjava.net.SocketPermission grantable Sojava.security.AllPermission denied nonjava.security.SecurityPermission denied nonjava.util.PropertyPermission grantable Projavax.tv.media.MediaSelectPermission grantable Mejavax.tv.service.ReadPermission grantable Sejavax.tv.service.selection.SelectContextPermission grantable sSejavax.tv.service.selection.SelectPermission grantable Seorg.atsc.application.ApplicationPermission grantable Xleorg.atsc.management.ManagementPermission grantable Sta

t org.atsc.preferences.PreferencePermission grantable Pre

org.atsc.registry.RegistryPermission grantable Reorg.atsc.security.AtscAllPermission denied nonorg.atsc.security.HAViPermission denied nonorg.atsc.user.UserPermission grantable Us
DASE 2001 Symposium

End of Presentation
NIST DASE Development Environment

Robert Snelick

Information Technology Laboratory 

National Institute of Standards and Technology 

rsnelick @nist.gov

The NIST DASE Development Environment is a collaboration effort of the National Institute of 

Standards and Technology (NIST) and the Advanced Television Systems Committee (ATSC) T3/S17

industry consortium for the proposed Digital TV Applications Software Environment (DASE) standard. 

NIST is directing their efforts towards the development of an ATSC Set-top Box simulation, a prototype 

implementation of the DASE Procedural Application Environment (PAE) Application Programming

Interfaces (APIs) and reference applications. The intended use of the development environment is to

demonstrate proof of concept of the DASE standard, provide the impetus for conformance testing, aid the 

design and development of other DASE implementations, and provide an environment for developing and 

testing DASE content/applications. In alignment with these goals, the design of the development 

environment emphasizes implementation clarity and portability over performance and system constraints. 

To achieve these goals, the majority of the system is written in Java. The NIST DASE Development 

Environment includes a runtime interface so that DASE Xlets can be easily created, run, and tested. All 

NIST produced source code, documents, and associated tools are placed in the public domain.

The core component of the development environment is an implementation of the DASE P AE. 

NIST has implemented the javax.tv, org.atsc, org.havi, and org.davic APIs. The PAE API implementation is 

currently built on top of the NIST STB simulation. The simulation is a collection of Java classes that 

encapsulate the functions of an ATSC STB environment. A central task of the Java simulation classes is to 

provide the implementation with ATSC data structures and associated data managers. A key aspect of the 

API PAE implementation design is an intermediate software layer, called the Hardware Abstract layer 

(HAL). The HAL provides an interface to the STB environment that hides the details of the underlying 

architecture from the implementation. It is envisioned that this multi-layered design will ease the task of 

porting the implementation to other receiver platforms.

The NIST DASE Development Environment also includes example native DASE applications,

Xlets, and developer tools. Native applications include implementations of an Electronic Program Guide 

(EPG) and Channel Browser. Example Xlets include a Stock Ticker, E-Commerce, and a Service Provider 

EPG with in-band tuning capabilities. The developer tools include a stream injector, PSIP browser, and an 

Xlet controller.

16

7
1

NIST DASE Developmen

Environment

Robert SnelickDASE 2001 Symposium
2

NIST: The Who and the What! Department of Commerce! Information Technology Laboratory ! Assist U.S. Industry! Forward-looking Standards! Research
3

Outline! Overview and Motivation! Development Environment

– STB Simulation Platform– PAE Prototype Implementation– DASE Native Applications and Xlets– Developer Tools

! Future Work! Summary
4

What is NIST doing?! ATSC STB Simulation! PAE Prototype Implementation! Example DASE Native Applications an! Developer Tools! Bundled together as a Development 

Environment
5

NIST DASE Development Environment Architecture

daseJ (~pJav

Hardware

Abstraction

Layer

D

App

D

Int

data flowmethod call

Implem

C

ATSC/MPEG

stream parser

transport 

stream

V

A

ATSC/MPEG

tables, Xlets, data

stream feeder

(NIST defined bitstream)

NIST Defined Bitstream Format (PSIP, data, PCR) Simulation Classes STB Simulation Control (MPEG bitstream) OR
6

Benefits of NIST Environmen! Proof of Concept! Conformance Testing! Application Development and Testing! Prototype Source Code! NIST is Neutral, 3rd Party! Public Domain
7

STB Simulation! Java Simulation of an ATSC STB ! Independent of other system components! Consumes streams containing ATSC/MPEG ! Data sink for API implementation! Maintains table consistency! Performs data management, not information 

management

! Extracts modules from the Data Carousel! STB Simulation is NOT real-time
8

STB Simulation Components

ATSC/MPEG

stream parser

transport 

stream

V

A

(MPEG bitstream)

Implementation ATSC/MPEG

tables, Xlets, data

stream feeder

(NIST defined bitstream)

Simulation Classes

• table extraction• synchronization of tables• data carousel extraction• access to tables & carousel• access to STB state

STB Simulation Control

• JVM• runs Xlets

NIST defined bitstream Format (PSIP, data, PCR) OR
9

PAE Prototype Implementatio! DASE-J (pJava 1.2, plus and minus)! JMF 1.0! Java TV (including JMF Player to STB! ATSC *! HAVI *! DAVIC *

* Implemented by NIST
10

PAE Implementation Architec

DASE-J (java.io, java.awt, etc.) & 

DAS

Applicat

Xle

DASE API Int

(javatv, atsc, hav

data flowmethod call

Implementation 

(javatv, atsc, hav

Set-top Box

Simulation

Hardware

Abstraction Layer

• abstracts STB• portable layer• provides system data to API• managers (xlet, data, etc.)
11

Hardware Abstraction Layer! Intermediate software layer between A

implementation and STB environment

! Common interface that abstracts lowe! Enables portability! Transforms meta-data to API objects

– Merges ATSC/MPEG tables– Maps to API objects
12

Data Flow Example

DASE Application Objects

API Java Objects

HAL Java Objects

Simulation Java Objects

getATSCVirtualChannelTable()

getHALVirtualChannel()

getService()

map raw virtual channel

data flow

ATSC/MPEG Data
13

NIST HAVi Implementation! Standalone implementation! Uses java.awt light-weight component

framework

! HAVi 1.0 currently ! Migrating to HAVi 1.1! Framework complete with base set of ! Fully compatible with AWT componen
14

HAVi Implementation Framew! Screen and Device Management! Base Components and Containers

– HComponent, HContainer, HVisible

! Simulated HAVi Compliant System

– HScreen: simulated STB 

! Background device (still image)! Graphic device (including basic window manageme! Video device (not implemented)

! All Standard Mattes

– Flat and Image– Still and Animated
15

DAE “Implementation”! Basic support for file carousel content! DAE Application Manager! Extracts modules from Data Carousel! DAE Framework (interface for browse! Displays content (currently supports H! Implemented with Java Swing (render

HTML)
16

NIST Environment Summary

EPG

Channel

Browser

Native

Applications Stock

Ticker Xlet

Selection

Xlet

Weather

Xlet EPG Xlet E

DASE Xlets

Java TV ATSC DAVIC HAVi 

DASE PAE API

daseJ

Data Manager Xlet Manager PSIP Tables 

Hardware Abstraction Layer

CarouselManager

Security

Manager

Tuner

Manager

Table Extraction Data Extraction Table Sync

Solaris Linux NT

Operating System Platform

JVM PCR Manager Parser

Simulation
17

Implementation Status! STB Simulation

– functions necessary for implementation

! PAE Implementation

– prototype implementation– missing/evolving functionality (security, ARM, etc.– conformance tests forthcoming

! DAE Prototype Implementation

– framework– thin
18

DASE Applications and Xlets! Electronic Program Guide (EPG)! Channel Browser! User Preferences! Stock Ticker Xlet! Provider EPG Xlet (tuning via the API)! E-Learning Xlet! E-Commerce Xlet (HTML, no back-channel)! Weather Xlet
19

Developer Tools! Stream Encoder (Simulation)! Transport Stream Feeder ! Meta-Data Browser ! Software MPEG Parser (De-multiplexor)! API Unit Tests! DTV/STB Simulator (remote/controller/displa! RunXlet! Xlet Manager Viewer/Controller
20

Runtime Environment

Stream

Feeder

Meta-Data

Browser

Xlet

Control/

View

> tools.simulation.RunXletRunXlet > applications.xlet.stock.StockTicker

DTV/STB

Controller

DASE Environment

Simulation

Xlets, PSIP, data

PSIP
21

Stream Feeder/Meta-Data Bro
22

Electronic Program Guide (EP
23

Channel Browser
24

Stock Ticker Xlet
25

Stock Ticker Xlet

! Implement Xle! Acquire HAVi ! Open Carouse! Build HAVI sc! Start Xlet! Add Carousel ! Refresh Cache! Read Quotes! Update scrollin

TV Display

StockStreamer

StockText

StockTickerXlet

QuoteList

Simulation

read

generate random 

quotes

(carousel module)
26

Xlet Viewer/Controller

! Debugging too! Indicates the s

Xlets

! Start, pause, a

destroy Xlets

! Handles multip
27

Resources! http://www.dase.nist.gov! Implementation Source Code! Data Sets! User’s Guide! NIST Implementation Guide! Java Doc! Xlet descriptions and source code
28

Future Work! Tie-up Loose Ends! Port to real-time STB! Performance Measurements! Develop Metrics! DAE Implementation! DASE-2
29

Summary! DASE Development Environment

– STB Simulation Platform– PAE Prototype Implementation– Sample Xlets– Developer Tools

! Runtime Environment! Prototype Source Code! Application Development and Testing 
30

Team Members! Alan Mink! Robert Snelick! Wayne Salamon! Mike Indovina! Michel Courson! Guillaume Lathoud! Guillaume Marcais! Gaetan Guttermann
An Automated Approach

 for DASE Conformance Testing

Andrew Twigger

UniSoft Corporation 

Millbrae, CA 

andrew.twigger@unisoft.com

The successful implementation of digital television standards depends on the ability 

to consistently produce, broadcast and present content to the viewer. In an open market 

where multiple content providers, broadcasters and consumer electronic manufacturers 

are involved in the end-to-end process, the need for testing tools is paramount. The 

initial need to show component consistency and conformance to standards is essential to 

the successful development and implementation of digital broadcast systems. Once an 

installed receiver base is established and new equipment providing more advanced

capabilities appears on the market. conformance-testing tools will be needed to ensure 

that end-to-end broadcast compatibility is maintained.

This presentation describes an Automated Test Environment that has been

developed by UniSoft as a first step towards addressing the industry's need for testing 

tools. The Automated Test Environment provides a test laboratory emulation of a 

broadcast to the receiver and allows a test to simulate user interaction with the receiver 

through a remote control. The architecture of the Automated Test Environment is built 

using a flexible structure that is extensible for use in both receiver and application

content testing. This flexible design provides clearly delineated component boundaries 

allowing the technology to be used in terrestrial, satellite and cable operations and for 

testing applications and system components written to conform to different API

standards.

The current version of the Automated Test Environment is being used by five major 

consumer electronic suppliers to test their DVB MHP implementations. Extensions are 

already planned to cater for DASE and other digital television standards.

185
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

An Automated Approach 

DASE Conformance Test

Andrew Twigger

UniSoft Corporation

andrew.twigger@unisoft.com
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Objectives

!Design a flexible and comprehensi

Test Manager

!Implement a standard means to 

exchange information between the receiver and a computer workstatio

!Provide support for a wide variety o

purposes 

!Develop a security infrastructure 

suitable for use in a test laboratory
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Terminology

!Assertion!Test Suite!Test Set!Test Purpose [TP]!Test Manifest!TETware components

Test Case Controller [tcc]Test Case Manager
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Features and facilities

!Support for POSIX-style assertionbased testing!Test scenarios can be defined usin

powerful scenario language

!Test parameters can be specified u

a flexible configuration variable mechanism

!Configuration information and test 

results are recorded in a journal

!Support for the standard POSIX re

codes is built in
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

TETware Testing Mode

!The test harness and the test purp

all run on the system under test

!The list of tests to run is read from 

scenario file

!The results of tests are written to a 

journal
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

MHP Testing Model

!TCC does not run on the RUT, all 

control operations on a host system

!The test manager process provides 

interface between the TCC, the STand the other hardware componen
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Test Manager

!Based on publicly available 

TETware 3.3

!Provides the interface between 

TETware and the receiver under te[RUT]

!Defined interface to hardware 

specific code 
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

tcc

configuration

variables

scenario

file

per test suite

Test Manager block diagra

Delivery

subsystem

Reset

subsystem

Interaction

subsystem

User Input

subsystem

Media Capture

subsystem

Test

Manager

control

logic

journal
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Test Manager operation

!Determine test set geometry!Prepare broadcast streams!For each TP function:

Reset the RUTPlay the initial broadcast streamEnter a service loopWrite the result to a journalUnload the broadcast streamPerform reset operations
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

tcc

configuration

variables

scenario

file

per test suite

Delivery

system

Test Manager block diagra

Delivery

subsystem

Reset

subsystem

Interaction

subsystem

User Input

subsystem

Media Capture

subsystem

Test

Manager

control

logic

journal
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Test Manager Service Loo

!Respond to requests from the 

Interaction Subsystem

Start/Stop media capture operationsPress remote control buttonPlay out a transport streamLog messages to the journalLog result to the journal
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

remote

control

unit

tcc

configuration

variables

scenario

file

per test suite

Delivery

system

Test Manager block diagra

Delivery

subsystem

Reset

subsystem

Interaction

subsystem

User Input

subsystem

Media Capture

subsystem

Test

Manager

control

logic

journal captured media

files
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Test Set constituents

!Test manifest!Each TP:

One or more transport stream descripfilesA java class – the “Testlet” classSupporting java classes
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Test Manifest 

!Source of information about the tes!XML document!Describes:

Test purpose numbersApplicable MHP profiles and optionsConfiguration information affecting the execution of test purposesKey words identifying each TPLocation of transport stream description Reset operations required by each TPTest purpose time-out
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

test

manifest

test

applications

transport

stream

definitions

per test set

remote

control

unit

tcc

configuration

variables

scenario

file

per test suite

Delivery

system

Test Manager block diagra

Delivery

subsystem

Reset

subsystem

Interaction

subsystem

User Input

subsystem

Media Capture

subsystem

Test

Manager

control

logic

journal captured media

files
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Transport Streams

!Each TP consists of one or more 

transport streams [TS]

!TSs identified by channel number a

sequence number

!Typically short !Designed to be played in a looping 

manner
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Transport Stream Generatio

TS Description File Existing A

Stream

SoftOC

Test Transport Stream
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Transport Stream Generatio

From SoftOCPATPMTVCTApplication InformationDSM-CC

From A/V StreamMGTEITSTTVideoAudio
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Security Infrastructure

!Generate certificate chains (includi

badly formed certificates)

!Provide root certificates to receiver 

manufacturers

!Develop application signing tool an

hash file generation tool

!Create CRLs and root certificate 

management files
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Current Test Environmen

Modulator

Up Converter Linux PC StreamSource StreamStation 

Ethernet ASI ASI RF

PPP over serial connection
19 June 2001

An Automated Approach for DASE 

Conformance Testing 

Planned ATE Extension

!Automating the User Interaction!Supporting Audio/Video Capture!Return Channel support via a 

networked server

!Automating Test Manifest generati

application test capture and replay
ORBIT - OBJECT RECONFIGURABLE BROADCAST USING IT 

Pedro Botelho Cardoso 

INESC,Portugal,

pedro.cardoso@inescporto.pt, Tel: (+351) 222094200, Fax: (+351) 222084172 

Recent years have brought digital to broadcasting. In such a conservative environment as television, changes

are slow but consistent. After starting with transmission, archiving and playout, the move is now towards the postproduction environment. Current processing power and network bandwidth envisage in the near future that broadcast

solutions, based on proprietary technologies with limited multi-vendor integration, will be progressively replaced by

new alternatives adopting an IT approach based on open architectures, low cost generic hardware, distributed and

object-oriented paradigms. 

INESC Porto and BBC investigated the suitability of a distributed architecture using an IT approach to

broadcasting in the European project ATLANTIC (ACTS) and continued the work in ORBIT (a BBC funded project).

ORBIT is intended to provide, over two years (1999/2001), in a pilot implementation, a small-scale model capable of

handling "live" and recorded signals, from local and distant sources, of integrating media asset management and

content handling tools and of demonstrating the facilities and the interconnections which will be needed in a full-scale

operation. 

THE ORBIT PROJECT 

At the end of its first phase in April 2000, ORBIT had demonstrated the technical and economical viability of

the proposed architecture. This work led to presentations and/or contributions in several organizations: SMPTE, MPEG

and Pro-MPEG. An initial version of ORBIT is currently working at the BBC R&D laboratories and has attracted

significant interest. As a result several new projects are looking at the ORBIT technology as a possible middleware

solution. The demonstrator will be available to professionals to allow testing of the new methods and tools, for program

production, while providing feedback for tuning of ORBIT. 

THE ORBIT ARCHITECTURE 

MBE (Multimedia Broadcast Environment), the core of the ORBIT architecture, is an object based middleware

solution for the integration of essence and metadata in broadcasting environments. This framework provides the

architecture for full-scale deployment of objects in a network environment independent of their nature by using

CORBA and XML technologies. Where proven solutions and/or standards exist they are adopted into the ORBIT

architecture. Some examples are: the ASCA (SMPTE) proposal to define the control architecture and the application

programmer interfaces (APIs) for components comprising an advanced digital studio; the W3C tools for data

representation (XML based) 

and the MPEG-7 multimedia content description interface as the basis for data model development. 

The post-production environment is the main ORBIT use case. The applications use Java Beans and ActiveX

Components to demonstrate the functionalities needed: intake (live DVB and recorded material), logging, program

manipulation and editing. Dual capture intake (low and high-resolution material) enables most of the operations to be

carried with the low-resolution format reducing the required bandwidth. Final edit decisions can conform to highresolution material using ATLANTIC techniques manipulating LongGOP MPEG2 compressed format. 

CONCLUSION 

Television post-production is possible today using IT technology. Post-production components can be

implemented as software objects using CORBA and XML based middleware to establish control and communication

between components and to integrate metadata and content handling. The key to interoperability however is the

definition of the middleware interfaces and consistent metadata dictionaries and schema definition in international

standards organizations. 

199 
ORBIT

(Object Re Object Re-configurable Broadcast Infrastructure 

configurable Broadcast Infrastructure 

(Object Re Object Re-configurable Broadcast using IT

configurable Broadcast using IT

Pedro Cardoso

INESC Porto
A BBC perspective * A BBC perspective *

* Richard Store

* Richard Store
Why the need to change? Why the need to change?

• There’s more competition than ever• Good programme content is the key bu• Programme budgets get tighter• Technology has a part to play• Viewer and listener expectations get hi
How can technology help

How can technology help

An efficient production system should:• Provide information where and when it’s n• Avoid unproductive delays • Allow tasks to be done in the best order• Make the fullest use of its resources

There is a lot of scope for improvement!
So the changes that need to be ma

So the changes that need to be ma

Re-engineer our processes to capture and 

the metadata, keeping it linked to the media 

can provide them both, wherever and whenthey are needed.But the cost of doing this must be less than amount of money that we can save, otherwthere’s no business case. (nobody in their right minds would pay for it
Before Process Re Before Process Re

-engineerin

engineerin

Broadcasters have always had metadata - in many inaccessible and easy to lose forms; some of it has entered and lost many times.

This is expensive, wasteful and demoralisin
But the media chain has wo

But the media chain has wo

well for decades. well for decades.

Because we have had standards:Physical: VHS, C format, DI-5, Digi Beta, DVC...Electronic: PAL, Rec. 656, SMPTE 270M, AES/E

process process
Re-engineering the metadata 

engineering the metadata 

(relatively) easy. (relatively) easy.

Distributeto Metada(Data mode

IT Infrastructure

Most tools are already there: SQL, HTML, 

• The amount of data is low,compared to th• Sounds like a job for IT
To Re-engineer the engineer the metadata metadata you 

you 

Data Model to agree what the metadata means (SMEF - Stan

Media Exchange Framework)

XML to pass it around the system, along with the definitions (Databases and search tools to store it and find it again (varioA way of linking it to the corresponding media - e.g. a UMID (A way to implement your Business Rules, what data gets entewhen and by whom (ORBIT)A Project to put these all together and make them work (ORB
But what about the media? But what about the media?

Instant metadata is not enough. What if:

You’ve still got to wait a day for the tapes?You’ve got to wait another day because the content was wThe tapes are out on loan, lost, mislaid, damaged, obsoletIt takes three days to get your rushes onto the system?Someone got the description wrong?You’ve got to book a tape machine to view them?You’ve got to view the whole tape to find the bit you want?

Efficiency improvement requires quick, 

and in many cases instant, access to med

(Tapes are out networks are in?)
“Media” networks are VERY expe

“Media” networks are VERY expe

MetadataMedia

Big, expensive “Media” Network

capture playout

IT Infrastructure

Metadata linked through UMIDS SME

BB

££££ ££££ ££££

£££ £££
How about the Business Cas

How about the Business Cas

Savings must be greater than costsThe Media Network is the major capital c

Could this be another job for IT?
ORBIT

IT Infrastructure

capture playout

Puts media and metadata in one IT netw
Media Handling in an IT network ne

Media Handling in an IT network ne

Efficient media compression

Production quality for work in progressA range of “browse” qualities for different working meth

Efficient storage and transport

Current market offerings will not run on che

Network and resource managementLoad sharing

But ORBIT does
Orbit chose: Orbit chose:

MPEG2 - Long GoP for “production” quality• Gives 3 to 1 improvement in storage efficiencyMPEG1 - I frame only, for “browse” quality• Allows trick modes

These are pragmatic first choices. The sy

itself doesn’t care.
Long GoP MPEG2 for production qua• Gives the best quality for a given bit-rate• And - it’s an open standardBut:How do you: • Edit to frame accuracy?• Cascade without quality loss?• Get from compressed to component and back a• Change bit-rate without quality loss?
AC078

Participants in the Project:

British Broadcasting Corporation (BBC)Centro Studi e Laboratori telecomunicazione (CSELT)Ecole Nationale Superieure des Telecommunications (ENST)Ecole Polytechnique Fédérale de Lausanne (EPFL)ElectrocraftFraunhofer-Institut für Integrierte Schaltungen (FhG-IIS)Instituto de Engenharia de Sistemas e Computadores (INESC)Snell & Wilcox Ltd (S&W)

Advanced Television at Low bit rates And Net

Transmission over Integrated Communication s
Achievements of ATLANTIC Achievements of ATLANTIC

• Cascading with zero loss and inter-working betw

compressed and uncompressed

• SMPTE Standards - the Recoding Data Set (MO• Frame accurate editing including mixer effects• Bit-rate changing with no quality loss• Transmission and storage on low-cost IT netwo

servers

All based on Long GoP MPEG2 and demonstr

IBC97 and IBC98

Read more at http://www.bbc.co.uk/atlantic
Long GoP MPEG2 :

• Reduces storage and transport costs by 

• Brings forward the date when IT equipm

can do broadcast by 5 at least years

• For most applications, that means now
That’s bit That’s bit-rate out of the wa

rate out of the wa

what on earth is middlewar

what on earth is middlewar
Manual Integration Manual Integration

Essence Server Descriptive Data Server Devices .
Client Integration Client Integration

Essence Server Descriptive Data Server Devices .

UI
Middleware Integration Middleware Integration

Essence Server Descriptive Data Server Devices 

UI

Middleware
Existent middleware solutions pro

Existent middleware solutions pro

Connections across any networkA reasonable ability to inter-work between platforms and sDistributed processing for efficient use of resourcesSome common interface formats for dataBut:They’re designed for relatively small volumes of dataVideo is massive, so existing middleware won’t work
ORBIT Uses: ORBIT Uses:

For its implemenFor its informatio
Platform independent, Intel, Sun, IBM.....Vendor independentOperating system independent, Windows, Unix, Sun.....Implementations available Open SourceStandardised and published by the Object Management G

Provides a middleware foundation that 

Provides a middleware foundation that 

**Common Object Resource Broke
Provides a (meta)data communication format th

Provides a (meta)data communication format th

Is standardised by the W3C Consortium

Used and understood throughout the IT industry

Allows the data and its schema to be carried together 

XML eXtensible Ma

*
For its media transfer ORBIT use

For its media transfer ORBIT use

For moving its “work in pro

Material Material Exchange Exchange Format

For moving its source and programmes
MBEDIMICC For its media han

For its business r

ORBIT has developed its ow

ORBIT has developed its ow

Broadcast Middleware Broadcast Middleware
DIMICC Provides the media h

Provides the media h

It manages the hardware devices and software services iTransfers the production and “browse” quality essence Sets up and breaks down network connections as requireManages the location of media in the networkManages instantiation and distribution of services

*

*DIMICC, Distributed Middleware for multimedia Cont
DIMICC – Use Case Use Case

CORBA 

Naming Service

Essence

Server

Intake s

Browse sources

Full qualit

Intake GUI

status

Monitor.ocx

Intake

options

rec
MBE Provides the business r

Provides the business 

XML provides data model independence and allows evoluIt brings together the media and devices, using DIMICC, adescriptive metadata, using XMLIt implements the business rules - the who, the where and 

*MBE - Middleware for the Broadcas

*
ORBIT: the bottom line. ORBIT: the bottom line.

Uses best of breed technologies where they Uses commodity IT for metadata and essenHas developed efficient Broadcast Middlew

Provides an open API for application develo

ORBIT is a scalable and afford

broadcast infrastructure
ORBIT Project Timeline ORBIT Project Timeline

Phase 1 Phase 2

Phase 1 

Demonstrator

April

2000

October

1999

BBC Open Day
ORBIT at the BBC Open Days (May 

ORBIT at the BBC Open Days (May 

IP / ATM

Master

MXF

sources

AA

- intake, search, browse editing, metadata manipulation

Production workstations

content

server(s)

AAF

Conver

AAF

metadata

server(s)

Intake

MXF
EXCHANGE FORMAT HANDLING THE MATERIAL (MXF)

Vitor Manuel Teixeira

INESC Porto, Portugal,

vitor.teixeira@inescporto.pt, tel:+ 351222094200, fax:+351222084172

With the introduction of servers and computing devices into the broadcast chain, the exchange of content as a 

file becomes a pressing need. Much work has been done on the system requirements of the new networked program 

chain and many goals have been defined, notably by the EBU -SMPTE task force for the harmonisation of standards. 

An area that needs urgent addressing is the file format, which will be used for the exchange of content between servers. 

There are a variety of file formats in existence, but none that could claim the title of the "standard" interchange file 

format. The G-FORS project partners are working hard in association with standards bodies, such as the SMPTE, trade 

organisations and corporations, such as the Pro-MPEG forum and the Advanced Authoring Format (AAF) Association, 

to develop and agree upon a format that is simple, flexible and extensible. This paper presents a format that achieves 

these goals and presents tools to allow creating applications from different vendors that interoperate.

THE G-FORS FILE FORMAT

The exchange of video as files is seen as the key technology that will enable interoperability between different 

systems. The identification of a simple file format that could handle video, sound and metadata was seen as a vital 

component for standardisation. G-FORS looked at the various proposals for such a format and decided the likeliest 

candidate was the Media Exchange Format (MXF) that is being formulated by the Pro-MPEG Forum and the AAF 

Association. G-FORS wanted a file format that would meet the needs of simple interchange as well as being resolution 

and compression independent. The partners in the G-FORS project actively adopted the MXF file format specification 

for their project. They are implementing and using the specification to ensure wide adoption of the Operational Patterns 

defined in the final MXF standard. MXF provides a 'wrapper' for signal interfaces and disk-based storage of television 

images, sound, data and associated metadata. Its foundations rely on the SMPTE KL V coding specification (SMPTE 

336M -Data Encoding Protocol using Key-Length- Value) that allows full flexibility and extensibility. A compliant 

MXF stream defines a base dictionary and its organization in a set of templates so that applications are able to wrap and 

unwrap essence and metadata in a common space.

THE G-FORS SDK

The SDK (Software Development Kit) is divided into two layers allowing developers to use either low-level 

functions, to access a stream based on the KL V structure with several levels of nested hierarchies, or high-level 

functions, to navigate in the metadata through a DOM (Document Object Model) structure and retrieve the encoded 

audiovisual data independently of its coded format. Currently the SDK is not required to decode the essence by means 

of plug-in codec architectures, still further work will allow its integration with other frameworks that provide this 

feature. This SDK contains test applications that allow developers to parse, dump and debug files and wrap and unwrap 

metadata and essence.

CONCLUSION

The G-FORS project forms part of the European Commission Information Society Technology Research 

program (1ST). Information about the project can be obtained at www.g-fors.com. The ideas coming out of the GFORS Project will be communicated to standards bodies such as the EBU and SMPTE. A core element of the project 

will be to build a demonstration system to show the benefits of file transfer using a generic format. The SDK generated 

within the project will allow third parties to create applications abstracted from the underlying stream syntax and

organized in a flexible way.

219
HANDLING THE MATERIAL 

EXCHANGE FORMAT (MXF) 

Vitor Teixeira

INESC Porto

DASE’2001 Symposium, June 19 – 20, 2001
Overview

• G-FORS project• File Format

– What is MXF ?– What does it do ?– How does it do it ?– Basics about MXF– MXF structure

• SDK – Software development kit

– How it is organized – Functionalities– How to integrate with real applications
What is G-FORS?

• Generic Format for Storage

• EC-funded project - Information Society Technologies programme“Reduce the cost of European programme production by m

content available in an efficient and cost effective way”

• 7 partners - commercial, public and research

BBC R&D; CRIL Technology; BBC R&D; CRIL Technology; Enertec Enertec; INESC Porto; Philips DVS; Snell 

; INESC Porto; Philips DVS; Snell 

THOMSON THOMSON broadcast systems broadcast systems

www.g-fors.com
G-FORS

• Implemented the file format that accommodates the broadcaster ne

– simple interchanges (tape replacement)– simple editable package (cut edits only)

• Uses a cost-effective infrastructure IT based• Delivers several flavors of essence integrated with metadata:

– Accommodate DV and MPEG within the same file – Guaranty a common metadata set of structure and 

descriptors

• Faster than real time transfers• Demonstrates possible integration with commercial partners outsid

consortium and interoperability

• Is has adopted MXF and is actively working with Pro-MPEG to mak

successful file format.
G-FORS demo scenario

“Toaster” Server

Laptobrows

vid

EDL

“Live” Mixer

video output

3 browse qualitycamera feeds

3 cameras with capture cartridgeand a radio link

3 full qualityfile transfers

Conformed programme

Authoring 
An Introduction – producing Essence and Met

Elaboration Analysis

Synthesis

Composition

Packaging

Delivery

Interaction

Commission

Consumption

Archiving

Capture

Production Post-production

Consumption Delivery
What is MXF ?

• An interchange file format to be used within the broadca

• An extensible file format• A compression agnostic file format• A versatile file format• A metadata aware file format

– Structural metadata– Descriptive metadata

• A stream-able file format• NOT an authoring format

– MXF allows editable packages with simple cuts– Complex audiovisual transformations and effects done w
What is MXF ?

• Over 2 year of hard work by a joint team:

– Pro-MPEG Forum in association with the AAF associatio

• Over 130 members, among the most active BBC, SONY, S

Wilcox, AVID, SGI, INESC Porto,...

• Specification divided into a set of documents

– Part 1: Engineering guidelines– Part 2: Format Specification– Part 3: Operational Patterns– Part 4: Descriptive Metadata sets– Part 5: Body formats

• These have all been submitted to SMPTE for ballot (Ap

and is open to the public (www.pro-mpeg.org)
What does it do ?

• MXF provides ...

– an extensible framework for interchanging Metadata and – independence from compression formats– a variety of operational patterns to fit different application– a means of encapsulating structural & descriptive metada– a means of relating the metadata with the essence– low level file structure for efficient storage and parsing– a means of indexing content for random access– a stream-able file format for real time contribution
MXF concepts

• Wraps: Essence and Metadata

– Essence Agnostic– Metadata defined by SMPTE, MPEG-7 and the 

group

• Key-Length-Value Coding (KLV – SMPTE 336M• Public dictionary (Registries)• Uses Unique Media Identifiers (UMIDs) to locate 

label essence
Wrapping the essence and Meta

These are all Content Components:

Essence Component (Video)

Essence Component (Audio)

Metadata Item

Essence Component (Other Data) Association Metadata (eg Timecode

Vital Metadata (eg Essence Type)

Content Package

Content Item Content Item

Wrapper

Content Element Content Element

Content Element Content Element

Content Element

Content Item

Content Element

Content Element

Content Element
Base infrastructure for MXF

• KLV coding

– Key: a unique identifier– Length: how long is the field– Value: what is the value of the field

So

K

System

K

L

Metadata

K

L

Picture

K

L
The KLV coding scheme

Dictionary Key Name Type Meaning

(Local)

Key Len Value

KLV 06 0E 26 34 01 01 01 02 01 05 08 00 00 00 00 00 18 47 6F 6E 65 20 57 ...

Not to scale

MXF 

Dictionary

(Public)

Lookup

Key Name Type Meaning01 05 08 00 00 00 00 00 Version Title ISO 7 bit The Version Title01 04 07 01 00 00 00 00 00 Edge Code ISO 7 bit Film Edge Code

Title
The KLV coding scheme

Dictionary Key Name Type Meaning

(Local)

Key Len Value

KLV 06 0E 26 34 01 01 01 02 01 05 08 00 00 00 00 00 18 47 6F 6E 65 20 57 ...

Not to scale

MXF 

Dictionary

(Public)

Lookup

Key Name Type Meaning01 05 08 00 00 00 00 00 Version Title ISO 7 bit The Version Title01 04 07 01 00 00 00 00 00 Edge Code ISO 7 bit Film Edge Code

Title

01 05 08 00 00 00 00 00 Version Title ISO 7 bit The Version Title

Gone With the wind
Dictionary for the Keys (regist

• Systems can share common metadata• Common repository for definitions• Systems can be extended either in terms of new 

metadata or new kinds of essence

• Vendors can add their on features
MXF file structure (basic)

Header

Dictionary

Material 

Package

Sequences

File 

Package

Sequences

Essence Descriptors

Segments

Essence 

Data

Essence Items

Preamble 

partition

Header

Metadata

Essence

File Header File Body 
MXF file structure (Complex)

• Multiple essence, index tables, run-in, repeated header 

Preamble

partition

Header

Metadata

Index Essence

Table

Postamble

partition

File Header Index File Body File F

(optional)

Essence 

Run

In

Postamble

partition

(optional)

Pr

H Body Index

File Header File Body 

Body Po Body Body Body

Header Partition Continuation Partition 

Index Body 

Continuation Partition Continuation Partition

H Po Po 
Compression Independence

• Different MXF body types can be KLV wrapped• Body types can be single essence or multiplexed• Body type is signaled in the first few bytes

– Enables early success / failure when streaming– Allow rapid identification of body types

• Metadata can be parsed even if essence type cannot be • Store & Forward devices can report compression type
Operational Patterns

• Operational Pattern 1

Structural

Metadata

Descriptive

Metadata

Header Metadata Body
Operational Patterns

• Operational Pattern 5

Title, ... Descriptor

Header Metadata Body

Overall Structure
Header Metadata

Production 

Segment 

1

Production TrackScene TrackTimecode TrackVideo TrackShot TrackAudio TrackAudio Track

Scene 1

Scene Key Point

Scene 2

Scene 3

Shot 1 Shot 2 Shot 3

Timeline edit unit Clip

Production 

Segment 2

Production 

Segment 

3
Structural Metadata

• Major elements such as “byte order” in the file• UMIDs for the essence components• Packages

– A group of tracks– Material package defines the “output” timeline– File packages define the “input” timelines

• Tracks defined so far

– Timecode, Video, Audio, Events

• Sequences of Segments

– i.e. how the video “clips” are ordered and fit together
Descriptive Metadata

• Depends on the use of the file• Current set is aimed at creating Broadcast Programs

– Production metadata: Titles, episodic information– Definition of scenes, shots, participants, awards

Header 

Metadata

Scene 1

Scene 2 Scene 3 Sc

Shot 1 Shot 2 Shot 3

Clip Tim

Prologue Pack

Scene 

Collection Root Sets (Preface, Ident & 

Content Storage) Shot 

Collection

Material 

Package

Production

Collection

File 

Package
How it is structured and define

• Defined in Unified Modeling Language (UML)• Public dictionary will also be released in XML form

Has 1

File 

Package

Has 1

Timecode

Track

Has 1

Timecode

Sequence

Has >=0

Picture

Track

Has 1

Picture

Sequence

Has 1

Picture

Segment

Has >=0

Sound

Track

Has 1

Sound

Sequence

Has 1

Sound

Segment

Has >=0

User Comment 

(AAF only)

Key Strong re

n Identifie

1

3 6

78

9 15

4

Has 1

Timecode

Segment

5

Has 0 

Picture Essenc

Descriptor 

1011

2 

Has >=0

Data

Track

Has 1

Data

Sequence

Has 1

Data

Segment

121314
• Referencing of one set to another

– UUIDs and UMIDs are used as the links– strong reference means one to one relationship– weak reference means one to many - both are used

K

L ID

K

L ID

K

L ID

K

L ID

Strong 

Ref Strong 

Ref

S

Weak 

Ref

How to connect metadata sets
Low level structure: Partition

• Divides file into partitions containing a single “thing”• Partitions have an integer number of sectors• Sectors are a defined size (default sector size: 4096)• The order of elements in a partition is defined• Ease the indexing process ...

File Header File Body File 

Pre Head Body Body Post Head Index Body Body Body Post 

Header Partition Foote

Continuation Partition

Post Body Body Body
Indexing Content

• Generic Index Table solution

– copes with CBR and VBR– copes with Temporal re-ordering– cope with predictive compression schemes– simple implementation for simple body types

Sample 0

System

element

Video

element

Audio

element

Data 

element

CBE

Sample 1

System

element

Video

element

Audio

element

Data 

element

Samp

System

element

Data 

element

CBE VBE CBE CBE CBE VBE CBE CBE CBE 

IndexEntry 0

start

Slice 1

start

Slice 0

start

Slice 1

start

Slice 0

start

IndexEntry 1

start

IndexEntry 2

start

Slice 0

start
Handling MXF

Software Levels of access from th

Applications

Software

Applications

Essence

Metadata

MXF File

File System

KLV layer KLV layer L2 – Mid level - KLV layer a

KLV items either to read or 

MXF layer MXF layer

L3 – High level – access fiindividual MXF persistent oL0 - Low level – basic accroutines

Streaming

Essence

Metadata

MXF stream

GFF Support GFF Support L1 – Low level – abstraction f

device 
MXF SDK

• SDK is a set of objects stored in a library that implement all 3 layer 

functionalities

• Implementation done in C++;• ANSI/POSIX compliant;• High performance;• Multi-platform, currently tested in:

– Win xx: as a dynamic library (DLL)– Solaris / Linux: as a static library (although in future implement

evolve to a dynamic lib)

• SDK developed in 3 phases:

– Low-level API (Transparent access to files, cartridges, network– Mid-level API (KLV-SMPTE336M compliant);– High-level API (MXF Compliant);
MXF SDK (Mid-level API) 

• SMPTE 336M compliant• KLV:

– Possible to parse/decode KLV data:

• Metadata• Essence

– Possible to encode essence into a KLV stream

• In a MXF application point of view

– Have to translate the key into a meaning (later to be impl

the MXF SDK high level)
MXF SDK (High-level API)

• Instantiate the metadata objects as well as serialized th

file;

• Navigate through the node objects (equivalent to the DO

Document Object Model)

• Possibility to follow the links (weak and strong reference

physically KLV nested

• Enhanced to read essence from the partitions• Possibility to interpret MXF data depending on the loade

dictionary;

• Events schemes to signal update on metadata;• Additional layer that loads dictionaries written in XML fo
MXF SDK stack

Essence

Metadata

MXF File

File System

Essence

Metadata

files

Cartridge Streaming

Essence

Metadata

MXF stream

Software

Applications

Software

Applications

MXF layer MXF layer

KLV layer KLV layer 

GFF Support GFF Support

MXFDictionary MXFDictionary

DOM/SAX DOM/SAX

Public Metadata

XML File

MXF 

Dictionary
Example application (demux

DATA

Klv File

File System

GFF

Support GFFKLV

GFFKLVKey1 GFF Suppo

GFFKLVKey2

GFF

Suppo

GFFKLVKey3 GFF Suppo

Application that uses a L2 (KLV layer) access to a fila file system
Simple KLV packetizer

Audio

AudFile

File System

GFF

Support

Vid File

Video

File System

GFF

Support GFFKLV 

Multiplexer 

Su

Mu

GFFSupport2 KLV

Audio KLV packs

GFF

Support

GFF

MuxSource

GFF

Support

GFF

MuxSource

GFFSupport2 KLV

video KLV packs

Esse

Fi

GFF

Support
Multiplexing application

Audio

AudFile

File System

GFF

Support

Vid File

Video

File System

GFF

Support

GFFKLV 

Multiplexer 

GFFSupport2 KLV

Audio KLV packs

GFF

Support

GFF

MuxSource

GFF

Support

GFF

MuxSource

GFFSupport2 KLV

video KLV packs

GFFKLV 

Multiplexer GFF

Support

GFF

GFF MuxSource

Support

KLV File

meta

File System

GFF

Support

KLV File

meta

File System

GFF

Support

KLV File

meta

File System

GFF

Support

GFF

MuxSource video KLV 

packs

GFF

Support

GFF

MuxSource video KLV 

packs

GFF

Support

GFF

MuxSource video KLV 

packs

GFF

Support
Program creation

Capture

Planning

Edit V

Definition File

Definition File

Program Spec

MetadataDictionary

Generate

Definition File

SDK SDK SDK 

Ingest Annotate Aut
Questions?

Places to look for more information:

www.g-fors.com

www.pro-mpeg.org

www.AAFassociation.org
An Optimal File Distribution Model for Data Broadcasting

Edwin A. Heredia

Microsoft Corporation 

1065 La Avenida, 

SVC-3 Mountain View, CA 94043 

eheredia@microsoft.com

With the advent of terrestrial digital TV, the conventional 6 MHz RF band can be used to support 

not only traditional TV programs (audio and video) but also data broadcasting services. The advantage of 

such services will be the opportunity to cover large segments of the population with bit rates much higher 

than the typical telephone modems used nowadays. The disadvantage of data broadcasting using terrestrial 

TV transmission is its one-way-directionality. Data flows only in one direction from the server to the client 

while the existence of a reverse path is less likely. However, multimedia documents such as the electronic 

versions of newspapers and magazines are good candidates for unidirectional transmission since they may 

be designed without requiring interactivity with a server. This class of documents requires the delivery of a 

large collection of files or objects such as images, text, animations, sound, video clips, and others. In this 

presentation we will examine a method to deliver those objects in such a way that user access time is 

minimized.

In this presentation we examine the problem of file delivery using data carousels. Transmission 

using data carousels requires that each of the application files be sequentially and periodically emitted

during a certain time segment that constitutes the service duration. From the decoder's perspective, the 

detection of files in carousels will trigger the download process. Depending on the amount of available 

storage, the decoder may choose to cache all the files prior to running the application or, instead, it may 

utilize a caching strategy of its own. From the emitter's perspective, it is necessary to transmit the collection 

of files in such a way that even decoders with little or no caching storage may be able to run the application. 

All data broadcasting standards indicate encapsulation formats that should be followed for data carousel 

transmission. However, little or no research has been done in the area of strategies to populate efficiently 

data carousels with files. If we have a large collection of files with heterogeneous properties such as size and 

access probabilities, is there a way to group them in one or more carousels for efficient transmission? This 

presentation addresses this problem and offers one strategy that attempts to minimize file access in noncaching decoders.

In this presentation we examine the use of multiple streams, each of which carries a separate 

carousel, as a means to address the problem of efficient delivery of files with heterogeneous size and access 

probabilities. We show that the multiple-stream strategy can be used in such a way that file access time is 

minimized and therefore, for a given broadcast bandwidth, the proposed file distribution model gives an 

optimal arrangement. Furthermore, by using the same algorithm repeatedly, one can determine the minimal 

required bandwidth for a given access time.

241
An Optimal File Distribution Model for Data Broadcasting

Edwin A. Heredia

Microsoft Corporation Silicon 

Valley Campus, Bldg. 3 

1065 La Avenida, 

Mountain View, CA 94043 

eheredia@microsoft.com

ABSTRACT

With the advent of terrestrial digital TV, the conventional 6 MHz RF band of NTSC systems can be used to 

support not only traditional TV programs (audio and video) but also data broadcasting services. The

advantage of such services will be the opportunity to cover large segments of the population with bit rates 

much higher than the typical telephone modems used nowadays. The disadvantage of data broadcasting 

using terrestrial TV transmission is its one-way-directionality. Data flows only in one direction from the 

server to the client while the existence of a reverse path is less likely. However, multimedia documents such 

as the electronic versions of newspapers and magazines are good candidates for unidirectional transmission 

since they may be designed without requiring interactivity with a server. This class of documents requires 

the delivery of a large collection of files or objects such as images, text, animations, sound, video clips, and 

others. Standards have been proposed to establish data carousels for data delivery. However, these standards 

only indicate encapsulation formats required for data identification, signaling, and transmission. One

problem that remains unsolved from the perspective of the data server is how to organize a large collection 

of files in carousels. In this paper we will examine an optimal method to organize files with heterogeneous 

properties of size and access probabilities in such a way that user access time is minimized.

1. INTRODUCTION

Terrestrial Digital TV, as defined in the US by ATSC A/53 [1], offers the option to deliver bit streams at 

rates as high as 19.3 Mbits/s in every 6 MHz channel of the original NTSC system. This bandwidth may be 

used in different manners. It may be used to offer 3 or 4 conventional TV services (audio and video) in 

standard definition, it may be used for one high-definition channel, or it may be used to deploy several data 

broadcasting services such as HTML enhancements or Java-based software. These data services may be 

independent of the TV programs, or they may be tied up with the TV programs themselves.

An important part for the development of multimedia transmission services is the standardization of data 

broadcasting. Both of the major players, DVB in Europe and ATSC in the United States, have agreed to use 

DSM-CC as the base encapsulation protocol for data carousel services. For transmission, files are segmented 

first into one or more DSM-CC blocks, and later each block is divided once more into multiple Transport 

Stream packets in accordance with the MPEG-2

243
Systems protocol. The resulting 188-byte packets are multiplexed with others sharing the same Transport 

Stream, and after channel encoding, they modulate carrier signals using 8- VSB (See Fig. 1).

While DSM-CC and other upper-layer data broadcasting protocols indicate how to modularize and identify 

files within the data streams embedded in the Transport Stream, they do not provide methods to efficiently 

distribute objects in the streams. If a small number of objects is transmitted per document, then such an 

organization may not be required. However, multimedia documents such as existing WWW newspapers and 

magazines are typically composed of thousands of files with different sizes and access requirements. For 

large collections of documents, some intelligent file distribution method over multiple streams becomes 

necessary to reduce file access delay and save bandwidth.

In this paper we address such a problem. Based on object sizes and their access probabilities, we develop a 

method to distribute objects in multiple streams in such a way that the average file access time is minimized. 

We show that the resulting optimization problem can be transformed into a particular form of the quadratic 

allocation model for which an algorithmic solution has

been developed. With bandwidth being very likely the most important commodity in the

determination of broadcast costs, methods as the one introduced here are needed for the efficient use of 

bandwidth in the deployment of future multimedia broadcast services.

Figure 1. Encoding system architecture for Digital Television.

2. STREAMS FOR DATA BROADCASTING

The ATSC standard A/53 [1] defines rules and constraints to build a Transport Stream based on the 

definitions of the MPEG-2 Systems protocol [5, 6]. The Transport Stream is the collection of 188-byte 

length packets delivered over a single 6 MHz frequency band. When using ATSC, the communication

channel throughput is around 19.3 Mbits/s. This digital pipeline can itself be partitioned into multiple

individual streams, each of which may use a guaranteed portion of the

244
total bandwidth. Here we use the term stream to refer to the collection of packets identified by a unique 

packet identifier or PID and transmitted at approximately constant bit rate (CBR).

Figure 1 illustrates the data multiplexing process that leads to the Transport Stream. Buffers with occupancy 

feedback are used to control and guarantee the rate of individual streams. However, due to video traffic and 

multiplexing priorities, data packets can be dispersed when inserted in the Transport Stream. In practice, 

such dispersion modifies the actual bit rate moving it above or below the intended target, but the use of 

receiver buffers ensure that these fluctuations have no major effects.

A sequence of files transmitted one after the other and repeated periodically as part of a particular stream is 

called a data carousel. The periodic transmission of files allows users to access files randomly. Figure 2 

shows a time-bandwidth diagram for a single stream showing the sequence of objects (or files) transmitted 

in the stream. In this example, two carousel groups distinguished by their colors are shown in the figure. 

The time segment occupied by the object represents the interval required for transmission of all the packets 

that compose the object. Notice that objects are transmitted sequentially with no free slots in between. Also 

in the same figure, the repetition time for object q1 is explicitly indicated. A long repetition time for an 

individual object implies a long user access delay during downloading.

For large documents with hundreds or thousands of files, avoiding long access delays may require the use of 

multiple streams. For example, high priority files should be placed in streams where small repetition times 

can be guaranteed, whereas low priority files could be queued together in separate streams. This is the 

problem addressed in this paper. Based on a priority measurement such as the object access probability, we 

develop an optimal allocation method to place objects in the proper streams in such a way that the average 

access time per object is minimized. The original results for this paper were described by the author in [9].

3. OBJECT ACCESS TIMES

A collection of objects (files, pages, or directories) Q = {q1, q2, ...,qM } is sequentially streamed at a constant 

bit rate of b bits per second as shown in Fig. 2. The access time for object k is defined as the time required 

for having the object available to any type of application software. Figure 2 illustrates that object access 

times have two components. The first one is the wait time,

245

Figure 2. Access time components when retrieving objects from a broadcast stream.
w, from the instant when the object is requested to the instant when the object appears in the stream.

The second component is the download time and represents the time required to recover all the object 

packets from the stream. If Sk is the size in bits for object qk and if b is the stream bandwidth, then the 

download time is Sk/b. Consequently, the access time for object qk is given by

(1)

If the object request happens to be just before the object appearance in the stream, then the wait time will be 

null. However, if the request instant is slightly after the first object header bytes, then w will be maximum 

and equal to the time needed for the object to circulate and reappear in the stream. Figure 2 shows three 

examples of possible wait times when accessing object q7.

Consequently, the wait time w is a random variable uniformly distributed between 0 and Wmax, with

(2)

If E{ } denotes the expectation operator, then E{w} = Wmax /2, and therefore:

(3)

A WWW server with Internet access can register the number of times each page is accessed over a period of 

time. Based on this information, an empirical measure of access probabilities can be found for the web sites 

and by extension for the files that compose the pages. Let p(k) be the access probability corresponding to the 

k-th object of the document object collection Q, then the overall average access time is given by:

(4)

For the single stream case described in the previous section, E{tk} is defined in Equation 3. In the next 

section, we compute E{tk} for the multi-stream case and use tA to develop an optimization problem whose 

solution gives the object allocation for minimal access time.

246
4. DISTRIBUTIONS FOR MULTIPLE STREAMS

For documents with a small object collection, a single stream is enough to carry the entire collection. In 

fact, multiple documents may be streamed together through the use of data carousel grouping such as the 

one provided by DSM-CC structures. However, for large documents the delivery may require multiple 

streams to guarantee small access delays. Streams are recognized by their packet identifier (PID) that labels 

the MPEG-2 Transport Stream packets. Current technology enables stream tuning by PID filtering in

transport processing chips. Stream tuning is fast and easy while the overhead comes from the wait and 

download times described in the previous section.

Audiovisual streams, program and system information (PSIP), and other MPEG-2 functions utilize large 

number of PIDs. Therefore, while multi-streaming is important for reducing access times, the number of 

defined streams should simultaneously be kept as small as possible due to hardware limitations in the 

number of PID filters that can be established at a given time.

Once more consider the set of M objects Q = {q1, q2, ..., qM} which for transmission purposes will be 

broadcast using multiple streams. Each of the objects has a size Sk and an access probability p(k) for k=l, 2, 

..., M. Let N represent the number of available streams and let Cj designate the j-th stream with bandwidth 

bj. An example of the distribution of 11 objects over three streams with different bandwidths is illustrated in 

Fig. 3.

An assignment matrix X = [xij] of size M x N is defined here, whose elements indicate whether an object 

belongs or not to a certain stream, that is

(5)

Assuming in principle, that object qk belongs to the arbitrary streaming channel Cj, then equation 3 can be 

invoked to compute E{tk}. This gives

if qk E C j (6)

The assignment matrix can be used once more to remove the "if' clause of the previous expression, which 

gives

(7)

The assignment matrix X is precisely the term we would like to determine following some type of 

optimization method.

247
Substituting equation 7 into 4, after some algebraic manipulation, it is possible to demonstrate that the 

overall average access time for a multi-stream object allocation, T A, can be written as

(8)

where the equation constants are defined as

(9)

Therefore, the optimization problem can be stated as follows.

Find the assignment matrix X = [xij] such that the overall average access TA is minimized, subject to the 

following two constraints:

The first constraint implies that the solution space is binary, meaning that an object mayor may not belong 

to a certain stream, whereas the second constraint indicates that an arbitrary object can be assigned to one 

and only one stream. Because of the quadratic form of the cost functional TA described in equation (8) and 

because the solution space is binary, this optimal allocation problem can be classified as non-linear integer 

programming problem of the zero-one kind.

In conventional data broadcasting applications, the stream bandwidths are negotiated a priori, and once the 

broadcast server admits such bandwidths in guaranteed mode, the rates are maintained at the defined levels. 

When all the selected data broadcast streams have the same bandwidth, the optimization problem can be 

further simplified. In this case, after defining the terms

(10)

(11)

From their definitions, it is clear that C and b are positive numbers, consequently, for the equal bandwidth 

case, a simplified cost function results:

(12)

248

,

then, the overall average access time becomes
subject to the same constraints as the previous non-uniform bandwidth case, that is:

Figure 3. An example of object distribution over multiple streams.

5. OPTIMIZATION ALGORITHM

The optimization model defined by equation 12 is similar to a particular form of the generalized quadratic 

assignment problem. This form is normally obtained when studying classroom scheduling problems (CSP) 

[8] or the allocation of interacting activities to facilities [2, 3, 4]. Like most of the known quadratic 

assignment problems, the existence of nonlinear interaction terms makes these, otherwise simple problems, 

NP hard.

Carlson and Nemhauser have proposed an optimization algorithm for the CSP problem applicable when the 

coefficient matrix is symmetric with null diagonal [2]. Under these conditions, local minima can be found 

through a recursive process. However, for the stream allocation case, it is evident from equation (10) that 

the coefficient matrix A is not symmetric and has, in general, a non-null diagonal. We show next that a 

reformulation of the problem is possible to meet the constraints imposed by Carlson and Nemhauser.

249
where

250

Figure 4. The top diagram shows the distribution of file sizes for each of the 150 files. The bottom diagram 

shows the distribution of access probabilities.

(13)

(14)

Let By inspection, it is evident that the matrix [Yik] is: (1) symmetric, (2) has

ones as its diagonal elements, and (3) has only ones or zeros as elements. Consequently, using these 

properties, equation 12 can be re-written in terms of Yik as:
The first summation of equation 13 is a constant and therefore, the optimization problem can be restated in 

simpler terms as minimize the function z which is defined as

(15)

subject to the same constraints as before. The matrix Ã = [ãik] is symmetric with null diagonal, and therefore 

satisfies the conditions required for using the Carlson-Nemhauser algorithm. This algorithm was

implemented as described in reference [2]. The only difference in our implementation of the algorithm is 

that we used two starting feasible solutions to calculate two optimal allocation matrices. Because the 

algorithm gives local minima, then we chose the best of the two solutions as the adopted minimum.

Figure 5. Average user access times as a function of the number of streams for blind

assignment (0) and optimal allocation (+).
6. APPLICATION EXAMPLE

Consider the problem of finding the proper number of streams to use when broadcasting a large WWW 

document. For this example, we assume that the document is composed of 150 pages with sizes as shown in 

Figure 4. The sizes were obtained using a uniform random number generator between 1 and 50 Kbytes. 

Using these values, the total document size is about 3.8 MB. For a probability distribution, we assume that 

from the total of 150 pages, 20 are considered highly likely to be accessed (hot pages) while the remaining 

130 have low access probabilities (see Fig. 4). Different probability and size distributions have no impact 

on the method, since the optimization procedure is carried out without any assumptions regarding these 

distributions.

Assuming an available broadcast bandwidth of 250 Kbits/s, we want to determine an efficient way to use 

the bandwidth for over-the-air broadcast. One option is to allocate the. pages uniformly (page 1 placed in 

stream 1, page 2 to stream 2, and soon). The second option uses the optimization procedure described in this 

paper. Figure 5 shows the results when the process is repeated for different cases with the number of 

streams ranging from 1 to 10. The figure compares the average access time for each of the cases.

When one stream is used the available bandwidth is entirely dedicated to that single stream. When N 

streams are used, each receives its corresponding fraction of bandwidth. It is evident in this case that blind 

multi-streaming (that is, without using optimization) produces no benefits and should be, in general,

avoided. When using optimization, the situation changes drastically. Figure 5 shows that multi-streaming 

helps reducing the average access time from 62 (one stream) to 48 seconds (three streams). Without 

optimization, such a reduction in access time can only be accomplished by increasing the available 

bandwidth from 250 Kbits/s to 320 Kbits/s (almost 30% of bandwidth increase!) Since bandwidth is likely 

to become a costly commodity in multimedia broadcast services, optimization methods like the one

presented in the paper are required to maximize efficiency.

7. CONCLUSIONS

Data broadcasting protocols such as the ones developed by ATSC [10] and DVB [11] will be used for the 

delivery of large multimedia documents composed of hundreds or thousands of files. The problem of 

distributing a large collection of multimedia files among multiple broadcast streams is studied in this paper. 

Based on measurement of priority (the object access probability), we demonstrate that the file allocation 

problem can be classified as a quadratic optimization problem of the zero-one kind. We show that through 

algebraic manipulation of the problem constants, the cost functional may be re-written in a form that is 

compatible with a similar problem studied by Carlson and Nemhauser [2]. The parameter that gets

minimized is the average user access time when downloading any page of the collection. We show as an 

example, that for a typical multimedia document composed of 150 pages with sizes ranging from 1 KB to 50 

KB, the optimization method reduces the access delay from 62 seconds (one stream) to 48 seconds (three 

streams). A reduction that otherwise would be achieved by increasing the transmission bandwidth about 

30%. Bandwidth reduction techniques, like the one described in the paper, will be necessary once multiple 

data services and television programs share the same communication channel and compete for bandwidth.

252
8. REFERENCES

1. ATSC A/53, Digital Television Standard, 1995

2. R. C. Carlson and G. L. Nemhauser, "Scheduling to Minimize Interaction Cost",

Operations Research, Vol. 14, No.1, pages 52-58, Jan -Feb 1966.

3. H. Greenberg, "A Quadratic Assignment Problem without Column Constraints", Naval

Research Logistics Quarterly, Vol. 16, No.3, pages 417-421, Sept. 1969. 4. H. Greenberg, Integer 

Programming, Academic Press, 1971 5. B. G. Haskell, A. Puri, and A. Netravali, Digital Video: An 

Introduction to MPEG-2,

Chapman and Hall, 1997. 6. ISO 13818-1, Coding of Moving Pictures and Associated Audio -Part 

1: Systems, 1996. 7. ISO 13818-6, Coding of Moving Pictures and Associated Audio -Part 6: 

Extensions for

DSM-CC, 1996.

8. M. Padberg, and M. Rijal, Location, Scheduling, Design and Integer Programming,

Kluwer Academic, 1996.

9. E. A. Heredia, "Optimal Object Allocation for Multimedia Broadcast", Proceedings

IEEE International Conference on ASSP, Seattle, W A, 1998. 10. ATSC A/90, Data Broadcast 

Standard, 2000 11. ETSIEN 301192, DVB specification for data broadcasting, 1997

253
Data Broadcasting Standards Overview 

Michael A. Dolan 

Industry Consultant, 

miked @tbt.com 

Data broadcasting covers many technical areas. This presentation provides a brief overview of the

application requirements for the entire system, including authoring through the receiver. Then, a review of

all the public standards efforts is provided in this context, including ARIB, ATSC, DVB, and SMPTE.

Finally, a few comments are provided on efforts at harmonization of these efforts. An extensive references

list is included which will supplement the presentation for further reading in the field. 

25

5
20-June-01 © 2001 Michael A Dolan

Michael A. Dolan

20-June-2001

NIST/ATSC Symposium: End-to-

Data Services, Interoperability an

Applications

Data Broadcasting Standar

Overview
20-June-01 © 2001 Michael A Dolan

Overview

• Data Application Scenarios• Data Application Infrastructure• General Technologies• Standards Organizations• Standards Work• Example• Detailed References
20-June-01 © 2001 Michael A Dolan

Data Application Scenario

• Captioning/Teletext (for 25+ years!)• IP Transport• Webcasting/Datacasting• “Buy-This-Now”• “Send Me More Information”• Polling• Real Time Gaming• Web Browsing
20-June-01 © 2001 Michael A Dolan

Captioning & Subtitling

Image Courtesy of M
20-June-01 © 2001 Michael A Dolan

Teletext

Image Courtesy of M
20-June-01 © 2001 Michael A Dolan

Captioning (US)

• Analog TV Closed Captioning (ATVC

Specification

• Regulatory• Used mainly for closed captioning • Includes Extended Data Services (XD

– National Weather Service (NWS) Alerts– Misc Service and Program Metadata
20-June-01 © 2001 Michael A Dolan

Teletext (EU*)

• ITU Recommendation• Widespread deployment in EU• Never really caught on in the US• Carousel of pages• Applications such as train schedules• Often interactive (i.e. backchannel com

* term used loo
20-June-01 © 2001 Michael A Dolan

IP Transport

• Support for MPEG as a network UDL• Initial development being done with th• Well understood from Internet and VB• Basis for proprietary multicast webcas

& datacasting products and services

• May be useful for limited unicast forw

channel, but doesn’t scale well

* UniD
20-June-01 © 2001 Michael A Dolan

One-Button Interaction

• “Buy-This-Now”

– pre-arranged business model and shippin

• “Send Me More Information”

– pre-arranged mailing info

• Polling

– Yes/No/Maybe
20-June-01 © 2001 Michael A Dolan

Gaming

• Real-time interaction• Play against TV or against other viewe• Game shows in use now in the US

– Jeopardy®– Wheel of Fortune®– Who Wants to be a Millionaire®
20-June-01 © 2001 Michael A Dolan

Web Browsing

• “Get More Information” in real time• Links to web sites from broadcast prog• Business model hard to support when 

distracted from the broadcast

• PVR Technology may make the busin

model work for this application
20-June-01 © 2001 Michael A Dolan

The Application Infrastructu

• Data Applications need:

– Basic Transport (i.e. MPEG)– Video/Audio Framework with Metadata– Data Framework with Metadata– Authoring Application Environment– Receiver Application Environment
20-June-01 © 2001 Michael A Dolan

Data & Timing Models

• Data Models

– Files– Streams– IP Packets

• Timing Models

– Asynchronous– Synchronized– Synchronous
20-June-01 © 2001 Michael A Dolan

General Environment 

Technologies

• ISO MPEG-2, DSM-CC, IETF IP Mul• HTML/XHTML

– W3C Recommendations “the web”

• Java®

– Sun Microsystems®

• Proprietary Systems

– Canal+®, OpenTV®, Wink®
20-June-01 © 2001 Michael A Dolan

Standards Organizations

• Studio, Facility & Distribution

– EBU, ISO/MPEG, ITU, SMPTE

• Digital Transports

– ARIB (JP), ATSC (US), ETSI/DVB (EU)– ISO/MPEG (INT), SCTE/OCAP (US)

• Consumer Electronics

– EIA (US), IEC (EU), EIA-J (JP)
20-June-01 © 2001 Michael A Dolan

Production Post-Production Distribution Emission Re

SMPTE/EBU

ATSC

DVB

SCTE

ARIB

ISO/MPEG

ITU-R

I

Interactive Television 

Standards Body Scope

JapanUSEurope
20-June-01 © 2001 Michael A Dolan

MPEG-2 Transport

A/65A/90 MPEG-4 Series

B-10B-24

300-468301-192

MHP

DASE

MPEG ARIB ATSC DVB

Ap

Env

Tr

DDE

SMPTE
20-June-01 © 2001 Michael A Dolan

ISO/MPEG-4 version 2

• MPEG-2 & MPEG-4 Transports• Data & Timing Models

– MPEG-4 Encapsulations (Files & Stream– Synchronized

• Focus on Video with (File) Object 

Composition

• MPEG-J

– JVM, API’s still tbd
20-June-01 © 2001 Michael A Dolan

ARIB B24*

• MPEG-2 Transport• Data & Timing Models

– Data Carousel (Files), Streams, IP Packe

Triggers

– Asynchronous, Synchronized

• BML (XHTML-derivation)

– CSS1(+), DOM1(+), ECMAScript

* no public informa
20-June-01 © 2001 Michael A Dolan

ATSC DASE 1.0*

• MPEG-2 Transport• Data & Timing Models

– Data Carousel (Files), Streams, IP Packe

Triggers

– Asynchronous

• JVM

– PJAE, Java TV, org.atsc.*

• XDML

– CSS2(-), DOM2(-), ECMAScript

* includes p
20-June-01 © 2001 Michael A Dolan

DVB MHP 1.x*

• MPEG-2 Transport• Data & Timing Models

– Object Carousel (Files), Streams, IP Pack

Triggers

– Asynchronous, Synchronized

• JVM

– PJAE, Java TV, org.dvb.*

• XHTML

– CSS2(-), DOM2(-), ECMAScript

* includes p
20-June-01 © 2001 Michael A Dolan

SMPTE DDE-1*

• Transport-Independent• Data & Timing Models

– UHTTP (Files) carried in IP Multicast, T– Asynchronous

• HTML-4

– DOM0, CSS1, ECMAScript

* based o
20-June-01 © 2001 Michael A Dolan

Comparison Matrix

Technology ISO/MPEG ARIB B24 ATSC DASE DVB MHP SMPTE DAnalog Transport

X

MPEG-2 Transport X X X X [1]MPEG-4 Transport

X

Files XXX X XStreams XXX XIP Packets XX XTriggers XX X XJVM X XXPJAE [2] X XJavaTV X XHAVi X Xorg.atsc.*

X

org.dvb.*

X

HTML/XHTML XXX X XDOM XX X XCSS XX X X

[1] Transport Independe[2] MPEG-J is early wo
20-June-01 © 2001 Michael A Dolan

The $64 Question

• What is really needed for “interactiv

television” and “data broadcasting”

• There are arguments for both extremes

– None - program director fully controls th

viewer experience, so it can simply be dothe video

– Full edge-of-the-seat web-like interaction

• Answer: Something in between, but fi
20-June-01 © 2001 Michael A Dolan

Example Trivial Application 

• Network is the MPEG Program (mayb

– the channel, service, or virtual channel

• MPE using DSMCC Addressable Sect

– small variations between systems

• Signaled in PMT and special tables

– somewhat wider variation between system

• Announcement in Event tables

– virtually no compatibility between system
20-June-01 © 2001 Michael A Dolan

Impedance Mismatches Abo

• Studio - Distribution - Emission Interf• Between Transport Systems

– even the most trivial scenario can’t be ea

done

• Between authoring environments• Between receiver environments
20-June-01 © 2001 Michael A Dolan

Harmonization Efforts

• International scope required• Multiple interface points in distributio• Focus on emission/receiver:

– ITU-R WP6M– ITU-T SG9– ITU JRG-1
20-June-01 © 2001 Michael A Dolan

References (Organizations

• Association of Radio Industries and Business (ARIB), http://www.a

• Advanced Television Systems Committee (ATSC), http://www.atsc

• Digital Video Broadcast (DVB), http://www.dvb.org 

• Electronic Industries Alliance (EIA), http://www.eia.org• European Broadcast Union (EBU), http://www.ebu.ch• European Telecommunications Standards Institute (ETSI), http://ww

• International Telecommunication Union (ITU), http://www.itu.ch• Moving Picture Experts Group (MPEG), ISO JTC1/SC29 WG11, 

http://www.cselt.it/mpeg

• Society of Cable Telecommunications Engineers (SCTE), http://ww

• Society of Motion Picture and Television Engineers (SMPTE), 

http://www.smpte.org 
20-June-01 © 2001 Michael A Dolan

References (Transports)

• ARIB STD-B10, "Service Information for Digital Broadcasting System"• ARIB STD-B24, “Data Coding and Transmission Specification for Digital 

Broadcasting

”

• ATSC Standard A/65-A, "Program and System Information Protocol fo

Broadcast and Cable"

• ATSC Standard A/90, “Data Broadcast Standard

”

• ETSI EN 300 468-2000, “Specification for Service Information (SI) in DVB 

• ETSI EN 301 192-1999, “DVB specification for data broadcasting

”

• ETSI TS 101 812, “DVB Multimedia Home Platform (MHP) Specification 1

• ISO/IEC 13818-1, “Generic coding of moving pictures and associated audio 

information: systems

”

• ISO/IEC 13818-6, “Digital Storage Media – Command and Control

”

• SCTE draft DVS 311, “IP Multicast for Digital MPEG Networks

”
20-June-01 © 2001 Michael A Dolan

References (Content)

• ARIB STD-B24, “Data Coding and Transmission Specification for 

Broadcasting

”

• ATSC draft T3/S17 “DTV Application Software Environment (DAS• EIA 608-B, “Line 21 Data Services” [ATVCC]• EIA 708-B, “Digital Television Closed Captioning “ [DTVCC]

• ISO/IEC 14496-x, “Coding of audio-visual objects” [MPEG-4]• ITU-R Recommendation BT-653-2, "System B, 625/50 televisio

[Teletext]

• SMPTE Proposed 363M, “Declarative Data Essence, Content Leve

• SMPTE Proposed 357M, “Declarative Data Essence, IP 

Encapsulation

”
20-June-01 © 2001 Michael A Dolan

References (Other)

• Addison Wesley, Lindholm & Yellen, “Java Virtual Machine Specif

Version 1.0”, ISBN 0-201-43294-3 [JVM]

• ECMA, “ECMA-262 ECMAScript Language Specification” [ISO 16• McGraw-Hill, Chernock et al, “Data Broadcasting: Understanding 

Data Broadcast Standard”

• Sun Microsystems, “Java TV API Specification” [JavaTV]

• Sun Microsystems, “Java Media Framework, Version 1.0” [JMF]• Sun Microsystems, “Personal Java Application Environment Specif

Version 1.2A” [PJAE]

• W3C Recommendation, “Document Object Model (DOM) Level 2 C

• W3C Recommendation, “Extensible Markup Language (XML) 1.0

”

• W3C Recommendation, “HTML 4.01 Specification

”

• W3C Recommendation, “XHTML 1.0: The Extensible HyperText M

Language

”
20-June-01 © 2001 Michael A Dolan

Author Contact Informatio

• Michael A Dolan

– PO Box 1673, Alpine, CA 91903– 619-445-9070– miked@tbt.com

• Acknowledgements

– DIRECTV for their general support in the field– SMPTE for ongoing support in converging data broadcas

standards

– MRG Systems for several images www.mrgsystems.co.u
DVB-MHP: Technical Overview and Commercial Status 

Herve Creff 

GM, Product Marketing 

 CANAL+ TECHNOLOGIES 

www .canalplus-technologies.com 

hcreff@canal-plus.fr 

This presentation provides a technical overview of the DVB-MHP (Digital Video Broadcast project

-Multimedia Home Platform) standard, delivers the schedule of the MHP initiative and discusses the

commercial success of MHP. 

MHP has been designed as a standardized, end-to-end and interoperable solution for digital

interactive TV. The main goals are to ease the creation of interactive TV content and to allow for the

emergence of a retail market for digital TV terminals. 

At the client side, MHP is giving support to two software platforms, one (called DVB-J) being

JavaTM-based, the other (called DVB-HTML) being Markup Language (ML)-based. From the system point

of view, MHP is defining (for both DVB-J and DVB-HTML) an application model, a graphic model, a

security model, interactive and broadcast protocols, a signaling protocol as well as a selection of content 

formats. MHP specifies three application profiles: Enhanced TV featuring local interactivity, Interactive TV

featuring interactivity over the return path and Internet Access. 

Frozen in February 2000 by DVB, MHP 1.0 has been published by ETSI in August 2000. MHP 1.1

(introducing DVB-HTML) is expected to be frozen by DVB in June this year. The MHP test suite should be

adopted by DVB Q4, 2001. 

The first MHP compliant terminals will appear on the retail market before the end of the year. MHP

introduction is likely to be driven by the retail market and the deployment of Digital Terrestrial Television

(DTT). The European Nordic countries (for all networks), Singapore (for DTT), Australia (for DTT) and

Korea (for DTS) have officially announced their support to MHP . The issues that can potentially slow

down the MHP penetration are the migration issue (from a legacy platform to MHP), the cost of an MHP

terminal (wrt a legacy terminal) and the interoperability issue. 

MHP is a solid technical solution for iTV that has to be transformed into a commercial success.

2002 should be the year of MHP . 

273
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

DVB-MHP : technical ov

commercia

DASE 

20th 

GM, Pro

CANAL+ TE

hcref
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

Mis

! Mission : define a standardized, end-to-end a

interoperable system for interactive digital TV 

! Goal : ensure the development of an open ho

for digital TV terminals

! Goal : ease the creation of interactive TV con

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

The DVB-MHP 

! Supports two software platforms

" DVB-J : a JavaTM-based platform comprising a Virtual M

collection of Application Programming Interfaces (APIs), designed for the TV environment

" DVB-HTML : a Markup Language (ML)-based platform c

specific ML and a scripting language

! Defines for both DVB-J and DVB-HTML 

" An application model (application definition, application 

management, resources management)

" A graphic model" A signalling protocol" Transport protocols (broadcast and interactive)" Content formats for text, images, audio clips, fonts, etc." A security scheme to authenticate applications and secu

transactions

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

The DVB

! DAVIC 1.4.1 APIs

" MPEG APIs (incl. Section " Tuning API" Resource Framework AP" CA API" Locator API" JMF extensions

! DVB APIs

" org.dvb.lang" org.dvb.event" DVB SI API" User Preferences API" DSMCC API" UI API (extended graphic" Return Channel API" Application Management " Persistent Storage API" CA permission API

! JDK APIs

" java.lang (subset)" java.lang.reflect" java.io" java.util" java.util.zip (subset)" java.net (subset)" java.awt" java.beans" java.math.BigInteger" java.rmi (subset)

! Sun APIs

" JavaTV (without javax.tv.carousel)" JMF 1.0" java.security, java.security.cert, JSSE

(subset) 

! HAVi APIs

" awt extensions" TV widget set

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

DVB

! Fully in line with W3C recommendations: based on 

" Shares common basis with the XML world

! Defines

" A content format (as a selection from XHTML 1.0 mo" A presentation format (as a subset of CSS2)" An event model allowing for a fine grained synchroniz

content

" An interface to the document (as a subset of DOM2)" A script language (ECMAScript)

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

DVB

! = HTML functionality + :

" Complete integration within DVB-MHP standard (part of " Benefits from DVB-MHP application model" Benefits from DVB-MHP security scheme " Integration with DVB-MHP graphic model" Access to digital TV terminal resources through DVB-J A" Fine grained A/V synchronization" Remote Control type of navigation " Associated conformance regime to achieve interoperab

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

Three applic

! Enhanced TV

" Featuring local interactivity" TV browsing" Information retrieval services (news, sports, weather for

information, ...)

! Interactive TV

" Featuring interactivity over the return path" Allow for transactional applications : t-commerce

! Internet access

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

! DVB-HTML! New APIs

" Plug-in API" Bank card API (Open Card Framework subset)" Application storage API" Internet applications management API

! Application management over the return path! Resident applications management! Internet Access profile

What’s new 

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

! MHP 1.0

" Frozen by DVB : February 2000" Published by ETSI : August 2000 

! MHP 1.1

" Should be frozen by DVB in June 2001 

! Test suite

" Should be frozen by DVB Q4, 2001 

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

! First MHP compliant terminals are expected Q4, 2001 

Who 

! Likely to start with the retail market (e.g. in Germany)! In Europe, will be driven by Digital Terrestrial Televisio! Official decision to go for MHP : Nordic countries (all n

Singapore (DTT), Korea (DTS), Australia (DTT) 

Which are 

! Migration from legacy platforms! Cost of the terminal! Interoperability (test suite availability) 

Technical 

overview

Schedule

Commercial 

status

Conclusion
Copyright CANAL+ TECHNOLOGIES 2001 - This document shall not be communicated to any third party without prior writ

! A good technical solution for iTV (including Internet ac! Digital TV terminals to go on the retail market! Solves the content creation issue! Interactivity as a source of revenues (t-commerce)! Not yet a commercial success! Interoperability is the key issue! 2002 : the year of MHP 

Technical 

overview

Schedule

Commercial 

status

Conclusion
OpenCable Applications Platform 

Donald P. Dulchinos 

Cable Television Laboratories Inc. 

 D.Dulchinos@cablelabs.com 

This presentation describes the OpenCable Applications Platform, a cable industry initiative to

develop a common software platform to support a range of interactive television applications and services.

OCAP is designed to do so in a way such that these services and applications may run on any cable system

in North America, and run on any combination of settop box, television receiver or other device running

any operating system software. 

The presentation describes the OpenCable hardware specification upon which OCAP is designed to

run. Then it provides an architectural overview of the OCAP spec, including its incorporation of

presentation engine and execution engine elements. The role of JavaTV APls is described, and the elements

of a CableLabs license with Sun for those APls is discussed. Additional focus is given to elements unique to

cable industry and customer needs. 

The presentation concludes with a comparison of OCAP with DASE and other related

specifications, and suggests a roadmap by which these specs can be harmonized. 

281 
OpenCable OpenCable Application

Application

Platform Platform

Don Dulchinos

VP, Advanced Platforms and Serv

Cable Television Laboratories, I
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OpenCable Summary OpenCable Summary

• Objectives• Specify the nextgeneration digital 

consumer device.

• Encourage supplier 

competition.

• Create retail hardware 

platform.

• Results• Technical specs 

complete, openpublished.

• New vendors ha

entered the ind

• Point-of-deploy

securitymodules availabsupported. 
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Supporting 

Hardware and 

OS

OpenCable Device

Headend

Network Interface

DVS-313

POD Security

Module(s)

POD - Host InPHI - Copy Pr

Video 

Content

Internet 

Content

Other 

Content

OCAP

OpenCable Specificatio

OpenCable Specificatio

Operations

Support
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OpenCable OpenCable Objectives Objectives

• Support retail product developers

- Extend OpenCable to integrated

receivers, PVRs, etc. 

• Support interactive service develo

through common software applicaplatform. - portability of applications, 

including EPG, IPPV, etc. 
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OpenCable OpenCable Application Plat

Application Plat

• Middleware approach directed by 

CableLabs Board of Directors.- hardware- and OS-agnostic

• Business objectives.

- enable service/application portabili- preserve supplier diversity- encourage innovation.
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OpenCable Software OpenCable Software 

Architecture Architecture

NetworkProtocols

Host Device

Monitor EPG Application Protocols

OCAP Implementation

Execution Engine

Presentation Engine

Native

App

Hardware

Operating System

Cable Operator Specific

OpenCable Application Platform

O

Int

LEGEND

Appl

Boot

Other

SI

Network

POD

Other

VOD Others

Host Device Manufacturer Specific
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Motorola, Philips

PowerTV

TWC EPG, Foo

Hardware

TV Guide, Food.com

Microsoft

OS

Software

Apps

Cable

Scientific Atlan

OCAP OCAP

POD

Service Portability Service Portability
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

e.g. Motorola

e.g. pSO

EPG, VOD, Gam

Hardware

EPG, VOD, Games, etc.

e.g. WinCE

OS

Software

Apps

e.g. Panaso

OCAP OCAP

POD

Service Portability Service Portability

Cable Operator

Lease Boxes Retail Box
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Operating System

EPG VOD MAIL 

OS APIApplication SoftwareHardware Vendor Supplied

DHCT Hardware

Legacy Software Overvie

Legacy Software Overvie

• non portable• each application 

must be separately written to the operating system of each type of DHCT AND each network
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

5 

Applications

6 HW 

Platforms

2 versions of 

each application

60 SW Objects

Without Middleware Without Middleware
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

O

peratin

g S

ystem

EPG VOD MAIL 

OS APIApplication SoftwareHardware Vendor Supplied

DHCT Hardware

Middleware (Java Virtual Machine, HTML, ECM

Middleware API

Role of Middleware Role of Middleware

• Abstraction layer 

that makes every platform look the same to the application

• operating system 

and hardware agnostic
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

5 

Applications

All HW 

Platforms

2 versions of 

each application

10 SW Objects

Management Management -- retail with M/W retail with M/W
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Example Applications Example Applications

• Electronic Program Guide (EPG)• Impulse Pay Per View (IPPV)• Video On Demand (VOD)• Interactive sports, game shows• E-mail, Chat, Instant messaging• Games• Web Browser: Shopping, Home banki• Personal Video Recorder (PVR)
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OpenCable OpenCable Applications Platform Applications Platform

Monitor

OCAP Applications

EPG

VOD Browser

Operati ng Syst em

Hardware

OCAP Application

Programming

Interface

Legend

MSO Specific Presentation

Engi ne

Executi on

Engi ne Bridge

Host Device

Baseline

OCAPVendor
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OCAP Development Histo

OCAP Development Histo

• RFP process initiated in September 1999• Proposals returned October 15, 1999• Review of proposals completed in December 1999• vendor authors selected

– Liberate– OpenTV– Microsoft– PowerTV– CanalPlus– Sun– CableLabs, MSOs and Excite@Home

• Specification development began Summer 2000• Work expedited through the utilization of existing stan

and architectures; started with DVB-MHP 1.0
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Presentation Engine Presentation Engine

• High degree of compliance with DVB-MHP 1.1• Enable use of tools for developing internet co• Renders declarative content such as graphics

animations and audio

• Consists of 

– HTML 4.01– XHTML 1.0– CSS 1 and 2– ECMAScript 3– XML– ATVEF
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Execution Engine Execution Engine

• Approximately 90% compliant with DVB-MHP 1.0.1• Java Virtual Machine• Provides a general application programming environm

networking, file I/O, graphics, etc.

• Security built into the Java architecture• Provides for full TV application environment (with M• Features

– Application management through pJava APIs and XLET – Service Information and Selection through JavaTV APIs– Media control through Java Media Framework– Broadcast data through MHP DSMCC APIs– Network management and IP data access – Extensions from OCAP, HAVi, DAVIC, and DASE
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Sun License to CableLab

Sun License to CableLab

• Includes pertinent portions of JavaTV API and 

related IPR.

• JVM Implementation certified and licensed by 

CableLabs with no obligation to Sun.

• Sun Technology Compatibility Kit incorporate

OpenCable compliance test suite.

• OCAP can specify the Sun Java Virtual Machin

JavaTV as fundamental components of EE.
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Bridge

• Enables browser to take full advantag

resources in STB through the Java APIs

• Minimizes the use of plug-ins (native 

applications)

• Permits access by ECMAScript applicat

Java Class Libraries and Java program

• Permits access by Java programs to th

files
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Security Security

• Application authentication

– Digital Signatures– Certificates

• Permission levels for applications 

determines access to system resouand APIs--unsigned applications whave lowest permissions

• Encryption to protect private data
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Monitor Application Monitor Application

• Optional• Privileged unbound application• Cable system-specific• Control of application life-cycle, 

resource management, copy protection, reboot, etc.

• Upgradable
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OCAP Summary OCAP Summary

• Designed for two-way, cable environme• Support for wide range of applications a

content.

• Portability and uniformity of content di• Security and robustness.• Resource management.• Open standards.• Support for developers.
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

OCAP Status OCAP Status

• Draft specification first release for NDA 

vendor review - January, 2001.

• Public release OCAP 1.0 - ~June 2001• Test plan, test environment under 

development.

• First interoperability testing of applicat

on different implementations - Sept. 20
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Harmonization of Spec Harmonization of Spec

• OCAP• ATSC DASE• ATVEF• DVB MHP• ITU ? 
© Cable Television Laboratories, Inc. 2001. All Rights Reserved. 

Forum on Forum on 

Cable Interactive Servic

Cable Interactive Servic

• Promote cable platform to interactive 

service/application developers.

• Solicit input into OCAP specification f

developer viewpoint.

• Solicit developer input into interoper

test plans and certification of OCAP implementations.

• Recruit service developer contributio

areas of test tools, developer tool kittraining, etc.
Don Dulchinos

VP, Advanced Platforms and Service

d.dulchinos@cablelabs.com

303-661-3803
Audience Measurement Services in a DASE Environment

William Feininger

Nielsen Media Research 

William_Feininger@tvratings.com

Nielsen Media Research is the leading provider of television audience measurement and related 

services in the United States and Canada. Its National People Meter Service provides audience estimates for 

all national program sources, including broadcast networks, cable networks, Spanish language television, 

and national syndicators. Local rating services estimate audiences for each of 210 television markets in the 

U.S., including electronic metered service in 51 local markets. For over 50 years, Nielsen Media Research 

has provided reports that define the currency for advertising spending on television, which is the basis for 

free, over-the-air, cable and satellite broadcasting. During these 50 years, much has changed within the 

television environment, and Nielsen Media Research has adapted accordingly. As the industry enters a new 

era of in the distribution of entertainment programming via digital television, many new products and

services including enhanced/interactive broadcasts, interactive program guides, time-shifted viewing

through personal video recorders and T -commerce will be offered to consumers. This presentation will 

discuss the audience measurement services required for the future. As the Digital Application Software 

Environment deploys Nielsen Media Research will, once again, be called upon to provide audience

measurement services.

283
Audience Measurement in th

DASE Environment

Bill Feininger

Director, Software Metering Technolog

Nielsen Media Research
Agenda

• Technologies• Challenges• Relationships• Solutions
Broadcast Netw

Cable Netwo

Syndicators

Stations

Microsoft

DirecTV

Mo

S/

Pa

JavaT

OpenTV

Liberate

iBlast

Panasonic

Sony

Philips

A New Paradigm For Televi

Many New Players

Equipment Manufacturers

Middleware, 

Platforms & Processes

Content

Providers
The Road Ahead Is The Road Ahead Is

Filled With Change Filled With Change
Analog

TV 

Advanced

Set Tops

Digital Set Tops

DTV Int

Hardware

Solutions

Software

Engines

Solutions For A New Environment

Internet Game Consoles

Nielsen Hardware/Software Po
Analog Television

• Reliable frequency-based measurement

– One 6 MHz frequency = one channel model– Frequency probe the local oscillator for channel tun– Automated Measurement Of Lineups (AMOL)– “Toolbox” approach with constant improvements

Peoplemeter
Direct Broadcast Satellite

• First entrant to the digital world

and to software metering:

– DirectTV – Echostar/Dish – Successfully adapted current 

metering system to measure

– New equipment/design and 

new challenges

Low Speed High Speed

Audio Video

InOut

Manufactu

protocol
PC/TV

• Analog and Digital PC/TV Tuner cards are re

available and inexpensive

• PC/TV tuning allows for variable window siz

multiple windows, and multi-task capability

• Next convergent step - TV’s with operating s• Software solutions are required for this envir• Field trial underway
Digital Cable

• Analog/Digital Cable Set Boxes

– Additional digital premium tiers, PPV, sports tie– Motorola and Scientific Atlanta– NMR utilizing display readers– Working toward a software solution
- AMOL2 Video Code – Source, Date , Time

- Multi-level ... sec x sec

- Analog VBI-based

- Audio Code – Source, Date , Time

- Analog or Digital

- Suitable for DTV

A/P Measurement Techniqu

Applying codes to television content at distribution

Utilizing Fingerprint information for television conten

- Audio Signature – zero-crossing algorithm

Software measurement solutions
A/P Distribution 

Audio/Video Encode

Broadcast/Cable Net

198 09/11/97 12:32:04

Ne

New Monitoring Site

198 09/11/99 12:32:04

198 09

Satellite Uplink
Transitional Era – Requires relati
DTV Measurement

• Frequency measurement and AMOL mus• New measurement techniques necessary• New partnerships are required

DTV Techniques

Data Packet Audio Encoding Ne

Dev

ATSC Standards Identifying codes Audio 

Application

ATSC/DASE

Standards
DTV Development

• NMR-built device for current MKII meter and for ou

new A/P metering platform

– Audio correlation, PSIP reader– Data packet reader

• Building this approach as a prototype

Sample Audio

Correlate Avail.

Audio Sources

ID Channel

Feed
ATSC/DASE

• Powerful set top boxes becoming available

– Traditional audience measurement – Backhaul profiles to advertising community

• Interactivity offers content, ads, and response

– Mass impressions enhanced with response data by – Enhanced measurement of procedural and declara

content for advertisers will be key

• JavaTV applet resident on set-top

– Applicable to large and small markets

• Uses Service Information interfaces

– Lists of programs to build EPG’s, credit programs
Software Metering

• New media types

– Traditional programming (A/V streams)– Ad banners (bitmaps)– Other streams– Applications (procedural content)– HTML content (declarative content)– Electronic Program Guides

• New collection methods• New browser-based reporting system
Why Is Such Sophistication Ne

• Convergence• Interactivity• Advanced Analog• Digital TV• Personal Video recorders (PVR’s)

– Stand-alone boxes– Integrated in STB’s and TV’s

• Data broadcasting – a way to pay for digital• PPV and VOD – at last an economic reality• STB’s as networking gateways

Technology deployment is making the environment far more c

Thus, a broad array of measurement tools and relationships 
New Measurement System

Enhancements

Film/Broadcast

Material

Backoffice 

Servers Enhanced Broadcast Signal Insertion

NMR

Servers

Backchannel

Audience Measurement Data
What Lies Ahead

• DTV has arrived and is hitting the early 

adopters/high income/high education demos 

– NMR audio correlation for DTV will be key to 

measurement with MKII and/or A/P

– Data packet would be efficient– Audio encoding is an excellent approach to 

measurement

– DASE-based measurement solution
Hardware

Solutions

Parting Thoughts

• Planning for the future• Build business & technology 

relationships

• Integrating old and new systems• Software/hardware solutions• Leverage innovations• Nielsen is making the necessary investments• Measurement requirements are changing, and we need

industry-wide input

• Partnerships (both technical and business) are key
Questions ?
Managed Media Service Platfonn

Ravi Gauba and Klaus Hofrichter

Sony Electronics 

3300 Zanker Road, San Jose CA 95134 

TEL: +1-408-955-4351, FAX: +1-408-955-3030, E-mail: rgauba@arch.sel.sony.com

The Managed Media Service Platform (MMSP) is being researched and prototyped in the Sony US Research 

Labs. It is a service platform based on local audio-video hard disks with multiple TV tuners or an always-on broadband 

Internet connection to support a new breed of media services. The fundamental concept of the MMSP is that the client 

device hosts one or more media cartridges. Each cartridge contains separate disk space and a tuner, and is individually 

dedicated to one specific service provider who manages the content on the customer's disk. The content is accompanied 

with descriptive metadata, which enables selection of content on demand, based on the viewer preferences.

The MMSP research addresses the design and

implementation of a service environment, which takes 

advantage of digital audio-video technology to offer 

new kinds of viewer-centric media services. The MMSP 

client device stores the TV broadcast program or an 

online media stream continuously on an A V hard disk, 

along with metadata, which describe the content. The 

Metadata helps the service provider maintain and

control the storage of content on the client, based on 

policies set by the service provider and using the

viewers profile. The viewers profile is created and

maintained by the profiling engine, which tracks the

users viewing habits and his choice of programs. The 

metadata along with the viewers profile provides finegrain access to the delivered content and is used during 

playback to present the content in an interactive,

meaningful, television-oriented, personalized form.

Several service concepts have been

prototyped in the course of the research: Custom

News Service provides news stories that are always 

up to date and the lineup is presented based on the 

viewer preferences. The service also provides

multiple viewing modes like condensed viewing,

detail viewing or normal viewing described in detail 

in the paper. Movie Rental Service stores movies

based on the viewer's preferences. It allows the

viewer to unlock these movies and watch them

instantaneously. The News scenario and the movie 

rental are only some of the possible application of a 

MMSP system.

Other applications such as TV games, education, 

are also feasible.

Figure I above sketches the system configuration: the

MMSP cartridge hosts the tuner for broadcast content, an 

always-on broadband modem and a

dedicated hard disk in a service cartridge.

Cartridges are plugged and installed into the MMSP 

cartridge tower. After the installation the cartridges begin 

automatic content capture from the assigned service

provider.

The full paper about the MMSP introduces the 

technologies and business concepts that are involved in the 

development of the prototype. It covers in particular the 

design of the platform, the metadata and describes the 

show flow engine, which processes the metadata and the 

viewer profile to generate the presentation. The paper also 

addresses and compares the richer capabilities and new 

applications provided by MMSP when compared to today's 

digital video recording devices. MMSP enables new

applications, business opportunities and better service 

quality.

285

Figure I: The Managed Media Service Platform
A Managed Media Service Platform 

Ravi Gauba and Klaus Hofrichter 

Sony Electronics 

3300 Zanker Road, San Jose, CA 95134 

TEL: +1-408-955-4351, FAX: +1-408-955-3030, E-mail: 

rgauba@arch.sel.sony.com

Abstract 

The Managed Media Service Platform (MMSP) is a research project of the Sony US Research 

Laboratories. It is a software platform designed for residential customers that exploits the use of 

local audio-video hard disks with multiple TV tuners or an always-on broadband Internet adapter 

to support a new breed of media services. An MMSP client comprises a base station and one or 

more plug-in media cartridges, each belonging to a specific service provider. A media cartridge 

contains an audio-video hard disk to store data (media assets, metadata, code) and a TV tuner or 

a broadband Internet adapter to receive the data. A service provider is associated with a specific 

cartridge and manages the data stored on the customer’s disk. Media assets belonging to a 

service are presented on a TV display under consideration of the viewer preferences. 

1.0 Introduction 

The Managed Media Service Platform (MMSP) addresses the design and implementation 

of a service environment, which takes advantage of digital audio-video technology to offer new 

kinds of viewer-centric media services. The work described in this paper is based on lab research 

taking technologies such as Digital TV, broadband Internet, A/V storage and metadata into 

account. 

MMSP enables a personalized television experience by leveraging non-linear content and 

editorial structure for rich interactive content presentation in the home. This “fine-grain 

programming” along with content provider-driven storage management is a key differentiator of 

the MMSP compared to traditional A/V storage (e.g., PVRs). Since the content provider has 

editorial control and has exclusive access to the allocated storage on the service cartridge, the 

provider can manage the content, storing, removing, and updating media via either one-way 

broadcast or Internet delivery. 

 The goal of the project is to specify an architecture for deployment of audio/video 

services that use service management driven by metadata and user preferences. The MMSP 

provides an environment for managing A/V services along with their content (A/V data) and data 

assets (e.g. audio, text, graphics objects, etc) in the customers’ home. The system is based on an 

A/V media cache, which is controlled by service providers. It allows linking the content and 

assets together to provide a TV-like, video centric viewing experience. The platform addresses 

content delivery and service management issues and can be used to integrate broadcast and 

broadband data delivery. The MMSP client device stores a specific TV broadcast program or a 

broadband media stream continuously on an AV hard disk, along with metadata, which describe 

the content. The software deployed by the service provider on the client device uses metadata to 
maintain and control the storage of content, based on policies set by the service provider and 

using the viewer’s profile. 

 The viewer’s profile is created and maintained within the MMSP system, which tracks the 

user’s viewing behavior and content selection pattern. Metadata associated with the content 

provides fine-grain information about the delivered content to populate the viewer profile. The 

viewer profile along with service specific configuration of MMSP software components is used 

during playback to select content for presentation. 

 MMSP is intended to be implemented on a small, inexpensive base device that supports 

plug-in cartridges. Each cartridge contains a tuner and appropriate A/V disk storage for specific 

services. A consumer purchases the services individually, comparable to a game cartridge or a 

DVD. The costs of the MMSP base station and the cartridges may be subsidized, since the 

service delivery may include a service subscription fee. 

The following sections of the paper cover the overall system architecture and discuss the 

main components of the MMSP. Some example services developed for the prototype are 

discussed. This paper does not cover the content creation and authoring aspects. 

2.0 System Overview 

 Although the prototype implementation of the MMSP system is done in software only, it 

is necessary here to describe the envisioned hardware components as well. The design of the 

client device hardware plays an important role in the overall system, since the A/V cartridges 

manifest the resources linked to a certain service. The design described below implies that a 

dedicated cartridge represents a specific service. Alternatively, a single cartridge with larger 

capacity may provide partitions to host multiple services, but this approach would limit the 

flexibility and requires negotiating resource allocation across service providers. 

Figure 1: Data distribution with the MMSP 

The envisioned MMSP base device hosts one or more A/V media cartridges. Figure 1 

shows broadcast and broadband content feeds from the service providers to the MMSP service 

cartridges. The data streams consist of a mixture of A/V content, metadata, executable code and 

media assets. All incoming data is temporarily cached until the local cache management matches 

it against the local user profile. Irrelevant and obsolete content is removed from the disk. This 

strategy enables the service provider to use the same content stream for many clients, which is 

particularly important for broadcast content distribution. The service provider may or may not 

use individual data streams with pre-selected content for each client in a broadband distribution 

environment. 

 The MMSP base provides A/V output jacks to connect to a TV, and a set of service 

specific input connectors such as Ethernet for broadband Internet access, and RF broadcast TV 
input plugs. An infrared remote control is used to control the service access. The cartridges are 

connected to the system through a backplane that provides power, and analog and digital signals. 

The cartridges run independent of each other to capture and maintain the incoming content, but 

only one cartridge provides an output signal at any given time. The base station provides graphic 

and video rendering capability for the active cartridge. 

3.0 Service Platform 

The MMSP is designed to provide enhanced A/V services, which take advantage of 

metadata associated with content and local storage with service provider driven media 

management. The services are able to adapt dynamically to the customer’s viewing behavior. 

The MMSP base station comprises several software components, including a resource manager, a 

rendering engine, a broadband adapter, and communication facilities for the cartridges. 

Figure 2: MMSP client architecture

Each cartridge connected to the base station runs its own service specific software for 

content storage and management, viewer profile, content selection (so called ShowFlow) and 

presentation. A service provider may decide to implement any one or all of these components in 

a proprietary manner and ship it with the cartridge or to use default components that are 

customized by a set of configuration rules. This allows the service provider to differentiate their 

service functionality or to ease deployment. The shared software components running on the 

base station offer a defined API, which is used to access the presentation hardware and 

broadband Internet adapter. The software components in the cartridge and the base communicate 

with each other using an asynchronous event mechanism. 

The metadata provided along with the content by the service provider is used by the 

MMSP components such as the content manager and the profile manager to decide how content 

is stored and presented. The metadata schema used by the MMSP is a subset of MPEG 7 

metadata along with custom, service specific extensions. The service provider can also configure 

and control the client devices using command and configuration scripts, which are delivered to 

Broadcast 

Broadband 

Cache Manager

Managed Media Service Platform

Base Resource and Communication Manager 

Content ManagerProfile ManagerShowFlow ManagerPresentation Manager

Cartridge A 

Content ManagerCache ManagerProfile ManagerShowFlow ManagerPresentation Manager

Cartridge B

Operating System and Hardware

Broadband 

Adapter

Rendering 

Engine

Broadcast Adapter Broadcast Adapter
the client device along with the content. These scripts are used by the MMSP to configure the 

behavior of components like the cache manager. 

The metadata is delivered to the client along with the content and may use the broadband 

delivery mechanism or a broadcast channel. The content metadata is created during the content 

production. Most of the attributes can be imported from existing content databases. The service 

provider reuses the data structures and adds MMSP specific information. The following sections 

provide some details about the core components that drive the MMSP system. Content metadata 

enable the selection of content that fits the viewer’s needs. The content manager uses the 

metadata to determine the relevance of the available media assets. The viewer profile provides 

information about the user’s preferences. The ShowFlow component controls the presentation 

engine to visualize the content in a personalized way. 

3.1 Cache and Content Manager 

The cache manager is responsible for management of storage of A/V content, metadata 

and other assets delivered by the service provider. It evaluates incoming data using the 

associated metadata to determine if it fits the viewer’s profile. If required, expired or less 

relevant content is removed from storage to make room for new assets. Usually, storage will be 

kept full with content, and each storage operation requires deleting other content. The algorithm 

to identify the obsolete content is controlled by cache manager policies, which are specified by 

the service provider. Since the complete storage capacity of a cartridge is reserved for a specific 

service, the service provider is able to change and update the caching policies. This approach 

does not require any user intervention. Moreover, most of the use cases based on the MMSP

system do not allow for direct access of the content by the viewer. Instead, the service is 

comparable with a newspaper, where new content is delivered regularly, without direct influence 

of the subscriber over the delivered content. It is up to the service provider to exploit the user 

profile as much as needed. For example, the provider of a TV News application may on the one 

hand recognize viewer preferences (e.g. local politics, sports), but at the same time it is possible 

to maintain editorial guidance by enforcing the presentation of the top-story of the day, even 

when the profile setting does not cover this. The cache manager is also able to update specific 

content. For example, the service provider may instruct the client device to overwrite an obsolete 

piece of content if an updated version is available. This is a typical procedure in a TV News 

application, where new information is replacing outdated data, for example a weather forecast 

video clip. 

The service provider controls the content on the client device using the content manager. 

The service provider sends instructions regarding the content handling in the content metadata. 

The content manager then interprets the rules. The content manager validates, tracks, and 

authorizes content stored in the cache. It maintains a list of content and assets that are available 

for viewing. The content manager keeps track of all the content and checks if it is valid for 

viewing based on time and authorization. For example, after a movie is rented from a movie 

rental service, the content manager maintains a record of how much of the movie is viewed and 

how may times it is possible to watch the movie. 

3.2 Profile Manager 

The profile manager works with both the explicit viewer choices and the implicit viewer 

behavior. In the MMSP we define the explicit configurations done by the viewer and the explicit 

likes and dislikes defined by the viewer as viewer preferences. While the profile is the implicit 
viewer behavior learnt by tracking the viewer usage pattern. The profile manager tracks the 

viewer’s content usage and generates the profile using the metadata associated with the content. 

The service provider defines the impact (or weight) that viewing of a particular content 

generates. When a viewer indicates interest in a program by watching it, the system changes the 

user profile on one or multiple content categories based on the weight assigned to the each 

category of the active content. 

The profile manager uses statistics and analysis of viewing patterns and explicit indication from 

viewer to learn how much a certain content type is desired by a viewer. For example, a viewer 

can define in a movie rental service a preference for comedy movies, but never watch available 

comedy movies. This would cause implicit lowering of the weight of the particular category, 

without removing the generic “comedy” preference. 

3.3 ShowFlow and Presentation Manager 

The ShowFlow manager selects the content that is used for presentation to the viewer. It 

generates a list of content that is passed to the presentation manager. The list is determined after 

evaluation of the viewer preferences, the viewer profile and the metadata of the available 

content. The evaluation process is either controlled by a set of rules or custom software delivered 

by the service provider. 

The content provider may supply specific metadata tags for the content to support 

different viewing modes. If these tags are available, the viewer may select one of these viewing 

modes. Four different modes are available: normal, condensed, highlight and interactive. Each 

mode provides a different view to the content with varying level of detail and interactivity. The 

normal mode is the default mode for all content to be presented. The condensed viewing mode is 

used for an abridged version of the presentation. In condensed viewing mode the viewer will get 

an overview about the content but sections with less importance are not shown. The content is 

even more reduced in the highlight mode, where the viewer only sees parts of the presentation 

that stand out, with the consequence that the context of the presented pieces might get lost. The 

interactive mode gives the viewer the option to access more details and more complex 

navigation. 

For example in a movie download application, the normal mode provides an interactive 

menu to select and watch a movie. When selecting the condensed mode the movie presentation is 

shorter comparable to an abstract, but the full storyline is still present. In the highlight mode only 

the most exciting scenes will be shown, with little association between them. The interactive 

mode presentation allows activating options such as the directors’ comments on a particular 

scene, or additional information on the background music etc. 

The ShowFlow manager interacts closely with the presentation manager, which uses the 

rendering engine to display the content to the viewer. The presentation manager generates 

instructions for the rendering engine that define how the content is presented and how the viewer 

can interact with the application. The service provider has full control over the presentation since 

the ShowFlow and presentation managers are service-specific components. The rendering engine 

can present HTML or run Java bytecode. 
4.0 Example 

A number of different services have been implemented to demonstrate the MMSP

architecture, including Customized TV News and Movie Rental. These services use different 

kinds of business models, i.e. subscription and pay-per-view. 

4.1 Customized TV News Service 

Customized TV News is well suited for the MMSP. This service is intended to be based 

on a subscription business model where the viewer pays a monthly fee for enhanced, 

personalized, interactive TV news content. The content is offered to the viewer according to the 

local preferences in a TV-oriented way: The presentation is stream oriented and does not require 

the viewer to become active as the content is presented. Instead, the presentation manager 

arranges the separate news clips automatically to meet the viewing pattern of the viewer. 

The viewer sees the headlines in the beginning of the presentation in form of an animated 

table of contents. The table of content consists of a number of small teasers for the upcoming 

stories. The order of the news clips depends on a number of factors, including the viewer’s 

preferences, the viewing history, and the content provider’s editorial specifications. The latter 

factor enables the content provider to indicate important stories, which might enforce 

presentation of stories even if the preferences would not cover this particular story. The 

presentation of the table of content can be used by the viewer to express interest or disinterest in 

the separate stories. This may result in a change in the actual presentation order and the 

preference settings of the viewer. 

The actual news stories are shown after the table of content. The ShowFlow manager 

arranges the stories according the viewer’s rating, the available time and the preferences. The 

stories are presented in a sequence, with optional additional information such as related material 

(such as subtitles) or custom data such as stock-tickers. 

The viewer can navigate in the story lineup, but this is not required as the presentation 

automatically moves forward from clip to clip. This resembles the format of a moderated TV 

news show, with the added value that the selection of the content is highly personalized. 

Figure 3: Interactive TV News with metadata presentation 
4.2 Movie Rental Service 

The Movie Rental Service is designed to support a pay-per-view or rental business 

model. The client cartridge for this service stores a selection of movies fitting the viewer 

preferences. The service provider pushes movie files to the cartridge. The viewer may then rent 

one or more of these movies, which is immediately available since it was downloaded in 

advance. This service requires a back channel for the payment transaction. 

The content manager system keeps track of the rented movies and removes them once the 

renting period is over. The viewer can also mark movies that are available without actually 

renting them to prevent automatic removal. This allows the movies to remain in storage for a 

longer time. 

The application supports multiple users with different profiles. This enables the 

implementation of features like parental control and similar viewer-specific functions that restrict 

the types of movies available to a viewer. Figure 4 shows how these movies are presented along 

with trailers, images and additional information on the movie. 

Figure 4: Movie Rental Service 

5.0 Conclusion 

The MMSP is a software platform designed for a set top device. It provides support for 

personalizable interactive applications. The MMSP software is envisioned to be used in a base 

device that supports cartridges with a large A/V disk, tuner and service specific software. The 

platform provides support for the cartridges and for audio/video service management and 

control. The MMSP enables through service specific reservation of A/V storage capacity new 

types of applications, branding and business opportunities. Service providers manage a device in 

the customer’s home, as well as the content and the means of presentation of the content. This 

creates a close relationship between a specific provider and the customer. The service providers 

manage content on the customer’s cartridge based on viewer preferences, content metadata and 

usage history. 
6.0 References 

[1] TV-Anytime Forum: http://www.tv-anytime.org/

[2] MPEG 7: http://www.cselt.it/mpeg/standards/mpeg-7/mpeg-7.htm

[3] DASE API: http://www.dase.nist.gov/documentation.html

[4] HAVi UI: http://www.havi.org/

[5] MHP: http://www.mhp.org/
SMPTE 292M VANC 

A Practical Way to Handle 'Sticky' Data 

Jim Carruthers

Norpak Corporation 

10 Hearst Way 

Kanata, ON, Canada, K2L 2P4 

jim@norpak.ca 

The focus of much of the DASE and ATSC data broadcast standards is, as it should be, on emission.

However, for DASE to succeed we need to also consider the production chain prior to the point of emission.

While content can be inserted at the point of emission, much of the most compelling interactive content will

be generated as an integral part of the creative process. The technical solution needs to take into account

how content is created, timed to video/audio, stored, and retrieved in the end-to-end chain, including those

locales where the video is in its uncompressed baseband form. The V ANC portion of the SMPTE 292M

signal offers a simple yet powerful way to deliver data while using proven broadcast procedures and

processes. 

Since the VANC is part of the 292 signal the combined video, audio and data signal can be switched,

routed, stored and recalled using familiar processes. Captioning, metadata and interactive content injection

continue to be done at the same point and in the same way in the business process. The 292 V ANC space

has significant capacity. 

While the VANC can carry any type of content it is particularly useful for 'sticky' content such as

DASE data, which: 

• Originates as part of the original creative process and is integral to the overall viewer

experience. 

• Needs to 'stick' with the video and sound as the content makes its way from the creator,

through post-production, to the network headend and is distributed to the point of broadcast.

• Must be transparently stored and retrieved without the complications of locating it on a server

somewhere. Program delays of seconds, hours and even days are commonplace. In an

environment where content rarely makes money on first run, continued playout of the

complete experience, often at short notice, is a business imperative. 

295 
© norpak corporation

SMPTE 334M SMPTE 334M

A PRACTICAL WAY TO A PRACTICAL WAY TO 

HANDLE ‘STICKY’ DATA HANDLE ‘STICKY’ DATA

JIM CARRUTHERS PhD, PEng JIM CARRUTHERS PhD, PEng

CEO NORPAK CORPORATION CEO NORPAK CORPORATION

www.norpak.ca www.norpak.ca
© norpak corporation

NORPAK - WHO?? - WHO?? 

! Developer of the TV Data Broadcast concepts 

standards. Interactive TV again, and again

! The leader in TV Data Broadcasting kit - belie

of the world market. 22 years experience

! Over 3,500 NTSC/ PAL/ SECAM, 525/625 lin

systems in 42 countries. All major data formatAnalogue, serial digital, HD serial digital and Mvideo formats

! Encoders, receivers, bridges, monitoring and c
© norpak corporation

WHAT DATA? WHAT DATA?

Lots of data terms – VBI, VANC, NABTS, ATV

A90, DSMCC, metadata, data essence .... and growing. For purposes of simplicity lets talk atwo types:

"‘LAST CHANCE’ data. This is data which g

in at the time of emission. Data broadcast unrelated to the program video is a good ex

"‘STICKY’ data. A term I have been using t

across the idea that some data needs to be tightly bound to the video 
© norpak corporation

SOME DATA SOME DATA

!Needs to be synchronized with th

video and sound – captions, iTV triggers, or

!Not synchronized, but needs to s

with the video and sound, and

!Needs to stand the ‘test of time’ 

‘Murphy’s law’
© norpak corporation

‘STICKY’ DATA ‘STICKY’ DATA

! Most solutions are focussed on adding data a

point of emission. Fine for data unrelated to 

! ‘Sticky’ data is content that needs to be bou

V/A as it travels through multiple plants on ifrom the creator to broadcast 

! Needs to be transparently stored and retrie

without the complications of locating it on a ssomewhere. Delays of seconds, hours, days arcommonplace - and what about years down th

! Compelling DASE content will originate as an 

part of the creative process – will need to ‘st
© norpak corporation

FORWARD / BACKWARD FORWARD / BACKWARD 

COMPATIBILITY COMPATIBILITY

!Whether the signal is analogue, serial d

or HDTV the ‘sticky’ data interface shbe identical

! Applications such as captioning, VChip, 

ATVEF and DASE should interface to tdata encoder in the same way regardlethe TV standard used

! Makes the move from analogue to digit

HDTV simple and straightforward
© norpak corporation

DATA DELIVERY ARCHITECTU

DATA DELIVERY ARCHITECTU

CONTENT

CREATION

CONTENT

CREATION

DASE DATA PART OF

ORIGINAL PROGRAM

CONTRIBUTION

NETWORK

HEADEND

NETWORK

HEADEND

NETWORK MAY ADD

DASE DATA

LOCAL

STATIO

LOCAL

STATIO

MAY ADD LO

DASE DAT

DISTRIBUTION

Videotape
© norpak corporation

SMPTE 334M SMPTE 334M

! The standard for adding data to the SMPTE 

signal using proven broadcast procedures and processes

! VANC in the SMPTE 292M stream means th

combined V/S/D can be switched, routed, and stored using familiar processes

! Captioning, VChip, ATVEF and DASE interact

data injection continue to be done at the samin the process, using the same tools and in thway as it presently is done
© norpak corporation

ACTIVE

PICTURE

DATA

HANC

ANCILLARY DATA FORMAT ANCILLARY DATA FORMAT

VANC

LUMINANCE : 1920 OR 1280 BYTES

CHROMINANCE : 1920 OR 1280 BYTES

ANC PACKET

7-262 BYTES

ANC PACKET

7-262 BYTES

ANC PACKET

7-262 BYTES

ADF

(3) DID SDID DC DATA PAYLOA

0-255 BYTES 
© norpak corporation

VANC THROUGHPUT VANC THROUGHPUT

! EACH LINE OF LUMA OR CHROMA CARRIES:

#1920 X 60 = 115.2K BYTES/SEC (274M)#1280 X 60 = 76.8K BYTES/SEC (296M)

! EACH LINE CARRIES:

#115.2K X 2 = 230.4K BYTES/SEC (274M)#76.8K X 2 = 153.6K BYTES/SEC (296M)

! VANC SPACE CONTAINS:

#274M : LINES 1-20, MINUS 2 SWITCHING = 18 LINES#296M : LINES 1-25, MINUS 2 SWITCHING = 23 LINES

! THIS YIELDS:

#274M: 33.18 MBS #296M: 25.27 MBS 
© norpak corporation

125M

SD video

267M

SD 16:9

274M

1920x1080I

2

128

305M 

“packet data” 

i.e. MPEG

292M

1.485 Gbs

259M

270 & 360 Mbs

291M

ANC data

272M

Audio 

(HANC)

299M

HDTV audio 

(HANC)

334M

VANC 

mapping

ANCILLARY

DATA

VIDEO

FORMATS

(selected) (selected)

BIT-SERIAL

INTERFACES

TES7

TES7

TES7 

ENCODER STANDARD

ENCODER STANDARD
© norpak corporation

TYPICAL DATA ENCODING TYPICAL DATA ENCODING 

OPERATION OPERATION

VTR TES3 Encoder

ATVEF

DATA

SOURCE

Analog

Video

Time

Code

RS232, 

10-baseT

Analog

Video 

+

ATVEF

Triggers

VTR TES5 Encod

ATVEF

DATA

SOURCE

SDI (259M)

Video

Time

Code

RS232, 

10-baseT

ANALOG VIDEO (E.G. NTSC) SERIAL DIGITAL (SDI) V

(SMPTE 259M)
© norpak corporation

SMPTE 334M DATA ENCODIN

SMPTE 334M DATA ENCODIN

VTR TES7 Encoder

ATVEF/

DASE

SOURCE

HD-SDI (292M)

Video

Time

Code

RS232, 

10-baseT

HD-SDI (292M)

Video 

+

SMPTE 334M

DATA

TES7 accepts commands, and inserts 334M VANC data into 292M
© norpak corporation

DATA DELIVERY (CONTENT CREA

DATA DELIVERY (CONTENT CREA

CAPTION

CREATION

CAPTION

CREATION

CONTRIBUTION

NETWORK

HEADEND

NETWORK

HEADEND LOCAL STATION LOCAL STATION

DISTRIBUTION

Broadcast

Videotape

TES7 Encoder VTR

DASE

DATA 

SOURCE

VTR

CREATION

Videotape
© norpak corporation

DATA DELIVERY (NETWORK

DATA DELIVERY (NETWORK

CAPTION

CREATION

CAPTION

CREATION

CONTRIBUTION

NETWORK

HEADEND

NETWORK

HEADEND LOCAL STATION LOCAL STATION

DISTRIBUTION

Broadcast

Videotape

MPEG TES7

DECODE

& DEMUX

Routing

Videotape

VTR

259M

Server

Compressor

ADB7

292M

292M

292M

292M TES7 

292M Contri- 292M

bution 
© norpak corporation

DATA DELIVERY (STATION

DATA DELIVERY (STATION

CAPTION

CREATION

CAPTION

CREATION

CONTRIBUTION

NETWORK

HEADEND

NETWORK

HEADEND LOCAL STATION LOCAL STATION

DISTRIBUTION

Broadcast

Videotape

MPEG TES7

DECODE

& DEMUX

Routing

Videotape

VTR

259M

Server

Compressor

ADB7

292M

292M

292M

292M

PSIP Gen

TES7 

292M Distri- 292M

bution 
© norpak corporation

A MISSING (292M A MISSING (292M-MPEG) LIN

MPEG) LIN

MPEG

Encoder

/ Mux

292M

LAN

292M 

+

334M

TES7 extracts 334MVANC data and producesdata for an MPEG encoder

TES7 Bridge
© norpak corporation

EMISSION AREA OF A EMISSION AREA OF A

DTV STATION DTV STATION

ATSC

PROGRAM

ENCODER

PSIP

GENERATOR

MUX CAPTIONS

TES7

BRIDGE

292M

VIDEO

T

DT

INS

‘LAS

DAT

INCOMING ‘STICKY’ DATA
© norpak corporation

SUMMARY SUMMARY

! The best place to insert ‘last chance’ da

emission, as shown in the previous slide. speakers have addressed those concept

! ‘Sticky stuff’. Compelling content will be 

part of the creative process. Present muse of metadata takes off with DTV. Mopicture data, rights data, assets manageetc. It is suggested that SMPTE334M iway to handle ‘sticky’ data end-to-end.
Components and Advanced Functionalities of the Next Generation 

Interactive Programming Guide

Yakov Kamen

iSurtTV, 

Sunnyvale, CA 

Xakov@isurftv.com

We first describe the major components of the modern interactive programming guide (IPG), its 

organization and architectural requirements.

We then discuss the need for new schedule and channel management functionalities to simplify 

channel navigation. In this discussion the following set of advanced IPG functionalities is described:

adaptive last channel, single click channel reordering, automatic favorite list generation, non-linear channel 

scrolling, multiple view modes, fast search without keyboard, channel pause, etc.

Next we propose several possible implementations of IPG components and advanced

functions.

At the end several working advanced IPG prototypes are demonstrated.

307
June 20, 2001 

Advanced Functionalities 

of the Next Generation 

Interactive Programming Guide (

Yakov Kamen, iSurfTV

June 20, 2001
June 20, 2001 

Interactive Programming Guide (IPG) is asoftware product that allows the user to find necessary information associated with TV Programs transmitted over the broadband network (cable, satellite, ADSL, etc.). IPG is- the most important interactive application 

for Digital TV;

- the most attractive new source of revenue for

IPG broadband network operators

- the major user of STB CPU power and memory- the most lousily specified interactive application
June 20, 2001 

What does the user want from the 

A. Preview capabilities. Get info about the content on the screen 

leaving the channel (sneak preview or banner), if the content is inthim.

B. Simple and Fast Scroll. Find the best program to watch now, 

playing on the current channel is not what the user wants. 

C. Easy Search. If there is nothing (or not enough) to watch now, 

wants to search for something available at a later time.
June 20, 2001 

What does the broadband network pr

want from the IPG?

A. Promotion of his service. Constantly remind the user who is 

provider

B. Additional Source of Revenue. To use the guide as an adve

holder .

C. Minimal Tech support. IPG service is free (today) for the use

wants to support a free service.

D. Differentiation. The IPG has to be cool and has to differentiate 

service.
June 20, 2001 

Paper Guide Passive Programming Guide (PPG)

Developed for analog TV 

Interactive Programming Guide (IPG) 

Supports schedule-related manipulations for digital TV

Advanced Interactive Programming Guide ( AIPG)

IPG which supports one or more of the following advanced function

PVRInternetInteractive Applications (weather, sport, games, shopping, ban

IPG Classification
June 20, 2001 

Preview (Mini IPG)

Allows fast sneak information preview

Scroll

Allows fast search of the best currently available show 

Search 

Allows advanced search of the data in the TV schedule

Remote Controller (RC)Menu, Settings and Help

Allows to choose one of the components, to set service settings,

and find help

Major Components of IPG
June 20, 2001 

Preview (Mini IPG) Portal

Allows fast sneak information Allows multiple applica

preview navigation

Scroll My Shows

Allows fast search of the best currently Creates listing of recor

available show 

Search Recording Function

Allows advanced search of the data Provides all convention

in the TV schedule recording functions

Remote Controller (

Menu, Settings and Help Keyboard

Allows to choose one of the 

components, to set service settings, and find help

Major Components of Advanced IPG
June 20, 2001 

Only shows current event descriptionCan be either only translucent or only opaqueDoes not allow browsing of other channels without re-tuningCannot show advertisementsUnable to support PIP as a part of previewDoes not display the current time

Existing Functionality of Mini IPG

Show current event description Show detailed description (advanced IPG)Tune to the channelAutomatically disappear in 5- 10 sec Translucent or opaque implementation

Problems

Preview (Mini IPG)-1 
June 20, 2001 

Show current event description in multiple modesShow the next few event descriptionsCapability to browse channels with and without tuning to themTranslucent and opaque implementationCapability to show advertisementCapability to show PIP and browse in PIP modeShow the current time, on demandAdvanced Functionality of Mini IPG

Preview (Mini IPG)- 2 
June 20, 2001 

Shows future event descriptionUses a single font size for all usersOrders all channels by number only 

Existing Functionality of Scroll

Problems

Scroll-1 

Shows current information as a listing (grid)Shows advertisement as a part of the listingStays tuned to the channelAutomatically shows highlighted event descriptionTunes to a channel using its number
June 20, 2001 

Scroll-2 

Advanced Functionality of Scroll

Show only current information in different forms (by channel logos, eve

descriptions, channel numbers, screen snapshots)

Adjust font size by interactive zoomingShows single event description or a short list of coming eventsShows a page numberSort channels by A-Z, numbers, categoriesSort by popularityScroll in the “Mosaic” channel
June 20, 2001 

Search-1

Existing Functionality of Search

Problems

Uses the grid for a “toggling” searchAllows searching by title, phrase, time, day, channel #Allows searching by categories and subcategories

TV program and ads are invisible when in the search modeAlways searches over the entire data setCan not sort by similarity
June 20, 2001 

Advanced Functionality of Search

Search-2

Search in categories Adjust font size by interactive zoomingKeeps advertisement and current TV programon the screenShows a page numberSort results of the search by channel #, channel names, popularity, etc.Visual Search
June 20, 2001 

Remote Control

Problems

No memory function (like in cellular phone)Single last channel option

Advanced Functionality of 

Remote Controller

Using keys as memory buttonsMultiple last channels
June 20, 2001 

My Show

Problems

Recorded shows can not be sortedNo bookmarking capabilities

Advanced Functionality

Sorting of shows by A-Z, date recorded, categoryAdding notes and bookmarks to recorded shows
SMPTE Declarative Data Essence: 

Comparison to ATSC DASE 

John Barkley, Michael Dolan, 

NIST 

jbarkley@nist.gov

Chair, SMPTE DDE 

 miked@tbt.com

Michael Koo, Andrew McCaffrey, Len Gebase, and Murugiah Souppaya 

NIST 

Gaithersburg, MD 20899 

The 70th Anniversary Issue of Business Week recognizes both TV and the Internet as technologies which

have had a profound effect on the economy. Interactive TV (ITV) can be characterized as a convergence of TV and

the Internet. The effect on the economy of their convergence is expected to be significant. 

Neither TV nor the Internet would have been so successful without standards. Likewise, their convergence,

ITV, needs standards in order to succeed. !TV standards are needed in the following areas: content. receivers,

application initiation/termination, application synchronization with video/audio broadcast, and content delivery. 

The Declarative Data Essence (DDE) Ad-hoc Group of the D27 Technical Committee of the Society for

Motion Picture and Television Engineers (SMPTE) is developing ITV standards that provide basic functionality for

ITV embodying current practice, known collectively as DDE-l. The Advanced Television Enhancement Forum

(ATVEF) specification is the basis for the DDE-l effort. The T3/S17 Specialist Group within the Advanced

Television Standards Committee (ATSC) is developing the DTV Application Software Environment (DASE)

standard for the next generation of ITV. 

This paper summarizes the SMPTE DDE-l specifications and compares DDE-l to DASE. In addition, this

paper describes the functionality specified within DDE-l and DASE that enable content developers to present and

manage ITV applications. This paper compares DDE-l and DASE with regard to: content types, application

initiation/termination, synchronization, and content delivery. 

Content developers include producers of TV programs and commercials. TV programming consists of

entertainment segments interspersed with commercials. Entertainment and commercial segments are usually

produced independently from each other. ITV Content developers need to be able to develop content that runs on all

receivers, and that does not interfere with content developed independently by others. Both DDE-l and DASE

specify functionality needed for sequencing ITV applications synchronized with a TV broadcast. This paper

compares DDE-l applications (called "enhancements") and DASE applications, and gives examples of ITV

applications. 

317 
 

SMPTE Declarative Data Essence: 

Comparison to ATSC DASE

John Barkley, Michael Dolan, 

 NIST Chair, SMPTE DDE 

 jbarkley@nist.gov miked@tbt.com 

Michael Koo, Andrew McCaffrey, Len Gebase, and Murugiah Souppaya 

NIST 

Gaithersburg, MD 20899

1 Introduction 

Interactive TV (ITV) can be characterized as a convergence of TV and the Internet. Both 

TV and the Internet, as separate technologies, have already had a profound effect on the 

economy [BW70]. The effect on the economy of their convergence is expected to be significant. 

Neither TV nor the Internet would have been so successful without standards. Likewise, 

their convergence, ITV, needs standards in order to succeed. ITV standards are needed in the 

following areas: 

• Content: standards specifying ITV content types. Content producers must know which 

content types to use in developing ITV applications so that the creation and distribution 

packages are interoperable. 

• Receivers: standards specifying receiver behavior so that content displays the same on all 

receivers. 

• Application Initiation/Termination: standards specifying how ITV applications are initiated 

and terminated. Content producers must know how to start/stop their applications, and how 

to ensure that applications do not interfere with each other. 

• Synchronization: standards specifying how content is synchronized with the video/audio 

broadcast. Content producers must be able to synchronize their ITV applications to the 

broadcast video/audio so that the same interactive experience is provided to the viewer on all 

receivers. 

• Delivery: standards specifying how content is delivered to the receiver. 

The Declarative Data Essence (DDE) Ad-hoc Group of the D27 Technical Committee of 

the Society for Motion Picture and Television Engineers [SMPTE] is developing ITV standards 

that provide basic functionality for ITV embodying current practice, known collectively as 

DDE-1. The Advanced Television Enhancement Forum [ATVEF] specification is the basis for 

the DDE-1 effort. The T3/S17 Specialist Group within the Advanced Television Standards 

Committee [ATSC] is developing the DTV Application Software Environment (DASE) standard 

for the next generation of ITV. 
 

This paper1 summarizes the SMPTE DDE-1 specifications and compares DDE-1 to 

DASE.2 In addition, this paper describes the functionality specified within DDE-1 and DASE 

that enable content developers to present and manage ITV applications. This paper compares 

DDE-1 and DASE with regard to: content types, application initiation/termination, 

synchronization, and content delivery. 

Content developers include producers of TV programs and commercials. TV 

programming consists of entertainment segments interspersed with commercials. Entertainment 

and commercial segments are usually produced independently from each other. ITV Content 

developers need to be able to develop content that runs on all receivers, and that does not 

interfere with content developed independently by others. Both DDE-1 and DASE specify 

functionality needed for sequencing ITV applications synchronized with a TV broadcast. This 

paper compares DDE-1 applications (called “enhancements”) and DASE applications, and gives 

examples of ITV applications. 

2 DDE-1 Compared to DASE: Overview 

Table 1 provides a summary comparison between DDE-1 and DASE.3

 DDE-1 consists of 

seven specifications, three for content ([DDE1], [DDE1-DOM0], [DDE1-lid]), and four for 

binding content to broadcast streams ([DDE1-UHTTP], [DDE1-IPM], [DDE1-NTSC], [DDE1-

PAL]). DASE consists of eight specifications ([DASE], [DASE-DA], [DASE-PA], [DASE-API], 

[DASE-FONT], [DASE-SEC],4 [DASE-CONF], [ATSC-ARM]). 

In DASE, ITV applications are characterized as either declarative applications (DA), 

whose content types are primarily Web pages, or procedural applications (PA), whose content 

types are primarily Java. More specifically, in DASE, a DA is a collection of resources whose 

“root,” as identified by ATSC A/90 [ATSC-A90] application signaling [ATSC-ARM] (see 

section 6) is of type application/xdml+xml. A PA is a collection of resources whose root is of 

type application/javatv-xlet. 

DDE-1 specifies a DA type application. More specifically, DDE-1 applications, 

commonly called an “enhancements,” are analogous to DASE Purely Declarative Applications 

(PDA). PDAs are DASE DAs where every resource has a declarative content type. 

 

1

 Because of the nature of this paper, it is necessary to mention vendors and commercial products. The presence or 

absence of a particular trade name product does not imply criticism or endorsement by the National Institute of 

Standards and Technology, nor does it imply that the products identified are necessarily the best available. 

2

 The descriptions of DDE-1 and DASE functionality in this paper are based on the DDE-1 and DASE specifications 

available at the time of publication. Some of these specifications may undergo revision subsequent to this paper’s 

publication. Moreover, the descriptions of DDE-1 and DASE functionality in this paper are summaries. For details, 

see the specifications. 

3

 In this paper, features described as “specified” within DDE-1 or DASE means that behavior semantics for these 

features are specified within the DDE-1 or DASE standards. If features are identified as “not specified,” content 

developers should be aware that such features might not be supported in a particular implementation of a standard. 

4

 DASE Security is very much a work in progress and is not described in this paper. DDE-1 does not specify 

security features. 
 

DDE-1 DASE5

DA Content Types

text/html, text/plain, 

text/css, text/ecmascript, 

application/tve-trigger, 

image/png, image/jpg, 

audio/basic 

application/xdml+xml, 

text/css, text/ecmascript, 

DASE Common Facilities6

PA Content Types not specified 

application/java, 

application/java-xlet, 

application/octet-stream, 

DASE Common Facilities6 

 Application 

 Initiation/Termination triggers/triggers 

ATSC A/90 application 

signaling/triggers 

Synchronization triggers triggers 

Content Delivery

 IP Multicast over NTSC, 

PAL/SECAM, ATSC and 

DVB; or backchannel 

Broadcast using a subset of 

ATSC A/90 

Table 1: DDE-1 vs. DASE 

Receivers capable of running DDE-1 enhancements have two basic design concepts: 

• Embedded within the receiver is Web browser software. The broadcast video and audio can 

be referenced within the HTML document as the URL “tv:”. 

• The two media, TV and the Internet, are synchronized by embedding “triggers” within the 

broadcast. Triggers are content which upon receipt, signal enhancements to be 

initiated/terminated, or ECMAScript code to be executed within an enhancement already 

running. 

Every resource in a DDE-1 enhancement or DASE application is one of the content types 

as shown in table 1. Within the DDE-1 specifications, there is no equivalent to a DASE PA. For 

more information on differences in content types between DDE-1 and DASE, see section 3. 

Both DDE-1 and DASE specify functionality for the initiation and termination of an 

application. In DDE-1, enhancements are initiated/terminated by triggers. In DASE, applications 

are initiated by ATSC A/90 application signaling, and terminated by triggers. See Section 4 for 

more information.

Both DDE-1 and DASE specify functionality, by means of triggers, for synchronizing 

running ITV applications with the video/audio. However, DDE-1 and DASE triggers have a 

different format. See section 5 for more information about synchronization. 

 

5

 In addition to the DASE content types listed in this table, the DASE Security specification under development 

defines the additional content types: application/dase-manifest, application/dase-permission, application/dasesignature 

6

 DASE Common Facilities consist of the content types: application/dase-trigger, image/jpg, image/png, video/mng, 

audio/basic, video/mpeg, video/mpv, audio/ac3, application/font-tdpfr, application/jar. 
 

DDE-1 specifies the delivery of interactive content by either the broadcast or by means of 

a backchannel,7

 typically an Internet connection. DDE-1 specifies a content binding for NTSC 

and PAL/SECAM analog systems. Additionally, 3rd parties have specified its binding to ATSC 

and DVB. In all cases, the binding relies on an IP Multicast encapsulation of the data, as defined 

in DDE-1. DASE specifies interactive content delivery by means of the ATSC A/90 Standard.8

See section 6 for more information. 

3 DDE-1 Content Compared to DASE Content 

Table 1 shows the content types specified in DDE-1 and DASE. DDE-1 specifies content 

currently in widespread use not only in ITV, but also on the Web. DASE specifies content more 

recently adopted and under development by the [W3C], as well as additional types. In addition, 

DASE specifies Java content types for PAs, which can also be part of DASE DAs. The following 

subsections compare DDE-1 and DASE content in the categories of content markup, stylesheet, 

script, and document object model. 

3.1 Markup Content 

DDE-1 specifies HTML 4.0 [HTML4]. DASE DA specifies the content type 

application/xdml+xml which consists of a subset of XHTML 1.0. The markup content for both 

DDE-1 and DASE DAs are very similar. The content type of the root of a DASE DA must be 

application/xdml+xml. Although markup content for DASE DAs is specified primarily as an 

XML DTD, the receiver is not required in DASE to be a validating XML processor, i.e., to be 

capable of validating content relative to any arbitrary DTD. A DASE receiver is only required to 

validate markup content according to the DTDs defining the content type application/xdml+xml. 

3.2 Stylesheet Content 

DDE-1 specifies Cascading Style Sheets level 1 [CSS1]. DASE DA specifies a subset of 

Cascading Style Sheets level 2 [CSS2]. CSS2 includes the functionality of CSS1, and specifies 

additional selectors. These include new pseudo-elements, e.g., the first letter of a paragraph, and 

new pseudo-classes, e.g., a link which has been visited. In addition, CSS2 specifies new types of 

selectors, such as attribute selectors, which can identify markup elements by the presence of an 

attribute and/or attribute value, and parent/child selectors which can identify markup elements 

based on a parent/child relationships. 

3.3 Script Content 

DDE-1 specifies ECMAScript 2nd Edition [ES2]. DASE DA specifies ECMAScript 3rd Edition 

[ES3], which includes the functionality of ECMAScript 2nd Edition. In addition, ECMAScript 3rd

Edition specifies a “switch” statement, try/catch exception handling, and native regular 

expression objects. The functionality of these regular expression objects is modeled after regular 

expressions in Perl 5. 

 

7

 DDE-1 informatively defines “backchannel” as “a connection from a receiver to the Internet or back to some 

server.” 

8

 Backchannel functionality may be included in the next version of DASE, commonly referred to as “DASE-2.” 
 

3.4 Document Object Model 

The document object model for DDE-1 is Document Object Model Level 0 (DOM-0) 

[DDE1-DOM0]. DOM-0 generally has the functionality of the object model common to both 

Microsoft Internet Explorer 3.0 and Netscape Navigator 3.0. This functionality is currently in 

widespread use on the Web today. Figure 1 shows the DOM-0 Objects and their relationships. 

For these objects, DOM-0 specifies basic functionality for reading/mutating, and processing of 

events. 

DASE DA specifies a subset of the DOM Level 2 (DOM-2) Object Model, specifically, 

[DOM2-CORE], [DOM2-HTML], [DOM2-VIEWS], [DOM2-STYLE], and [DOM2-EVENTS]. 

Although the DOM-0 and DOM-2 object models are different, the DOM-2 object model includes 

most of the functionality of DOM-0 and more. DOM-2 specifies the reading/mutation of almost 

all elements of an HTML document, in particular scripts and stylesheets. With DOM-2, changing 

information on a page can be accomplished by mutation, rather than by replacing an entire 

frame. This is particularly useful when the amount of information to be changed is small, e.g., a 

number in a table. 

The DOM-0 event model is based on intrinsic events as specified in HTML 4 syntax. In 

contrast, the DOM-2 event model is more robust and its behavior more well defined. While not 

technically part of the DOM, both DDE-1 and DASE specify native objects in support of current 

practice. These are the “Window,” “Location,” “History,” and “Navigator” objects. 

Window

forms[] 

Document

frames[] 

History 

Location 

links[] 

anchors[] 

Navigator 

elements[] 

Hidden 

Password Radio Reset 

Submit Text Textarea 

Button Checkbox

Select options[

Instances of 

these objects 

may be 

images[] 

Figure 1: DOM-0 Objects and Their Relationships 
 

 

DDE-1 Enhancement 

DASE Purely 

Declarative Application

Producer Initiated 

trigger with name and URL 

different from current 

application; instantiation 

automatically or with 

viewer selection ([DDE1], 

4.4, 4.6.1, 5.3) 

ATSC A/90 application 

signaling; instantiation 

automatically or with 

viewer selection 

([DASE], 5.1.2.2); 

[ATSC-ARM], 5.4) 

Viewer Initiated not specified 

viewer navigation to 

content type 

application/xdml+xml 

([DASE-DA], 5.1.1.6.1.1.1) 

Producer Terminated trigger with script that 

initiates a navigation to tv: 

([DDE1], 4.6.1)9

application root entity top 

level window object 

executes window::close() 

([DASE-DA], 5.3.1.2.9.4.3) 

Viewer Terminated viewer navigation to tv: 

([DDE1], 4.6.1)9

 

viewer navigation to 

content types video/mpeg 

([DASE-DA], 5.1.1.6.1.1.2) 

or application/xdml+xml, 

([DASE-DA], 5.1.1.6.1.1.1) 

Table 2: ITV Application Initiation/Termination 

4 Application Initiation/Termination 

TV programming usually consists of entertainment interspersed with commercials. 

Content developers for ITV include producers of both kinds of content. Entertainment and 

commercial segments are usually produced independently. ITV content developers need to be 

able to develop content that runs on all receivers, and that does not interfere with content 

developed by others independently. 

DDE-1 specifies a simple ITV application initiation/termination capability, while DASE 

specifies a more complex capability of initiation, termination, and suspension (see 

[ATSC-ARM], section 5). For example, in DASE, when a viewer changes channel, a DASE 

application is suspended, and may resume under certain circumstances when the viewer returns 

to that channel. 

Table 2 summarizes the functionality within DDE-1 and DASE for initiating and 

terminating an application. The term “producer” refers to the content developer and the term 

“viewer” refers to the end-user interacting with the content. Within DASE, there is functionality 

for the producer to craft the application in such a manner so that the viewer can be granted the 

option for initiating/terminating an application. Within DDE-1, only the producer can initiate an 

enhancement. 

 

9

 Note that, depending on the implementation, a trigger for a new enhancement that arrives before the termination of 

the current enhancement may also terminate an application. 
 

Both DDE-1 and DASE specify receivers minimally capable of running only one DA at a 

time. Because entertainment and commercial segments of a broadcast are interspersed, producers 

of ITV applications need to be able to initiate content for their segment, and then, at the end of 

the segment, terminate their content in order to allow the next segment the opportunity to run. 

For producers, two approaches to accomplishing this are as follows. 

The first approach is for segment producers to develop a DA that establishes control of 

the receiver at the beginning of their segment, and releases this control at the end of the segment 

so that the application for the next segment can run (see table 2). In this approach, a DDE-1 

enhancement (an HTML document) or a DASE PDA (an XDML document) is instantiated and 

displayed by the receiver. In DDE-1, this is accomplished by the producer creating an 

appropriate SDP (Session Description Protocol) record if Transport B (see section 6) and sending 

a trigger referencing the URL of the new enhancement. In DASE, the producer uses ATSC A/90 

application signaling to initiate a new PDA. In DASE, the producer can also provide the viewer 

a link within the currently running application to initiate a new application. 

When a segment ends, DDE-1 enhancements can be terminated by a trigger that 

navigates to the URL “tv:” from the topmost page of the enhancement, or by a producer provided 

viewer selection within the currently running application that navigates to “tv:” from the topmost 

page. Navigation to “tv:” from the topmost page also displays full screen video. 

Termination of a DASE DA can be accomplished by a trigger that results in the execution 

of a window::close() within the root top level window object, or by a viewer selection within the 

currently running application which causes the application root top level window object to 

execute window::close(). In addition, viewer navigation from the root top level window object to 

a root entity, which is either content of the type video/mpeg or application/xdml+xml, terminates 

the current DA. If the content type is video/mpeg, then full screen video is displayed. If the 

content type is application/xdml+xml, then that content becomes the new DA. 

The second approach is for producers of several sequential segments to share the topmost 

page of an application. For this approach, content for each segment is presented by means of 

frames subordinate to the shared single topmost page, which serves as an “executive” for frames 

associated with the segments. The first approach, described above, is used for 

initiation/termination of the topmost page of the application. Both DDE-1 and DASE specify 

functionality which allows an application to be present in the background while the viewer sees 

the video full screen, as though there were no application running. This is a particularly useful 

feature for this second approach. The viewer is given the choice of opting out of the interactive 

experience while the application continues in the background, ready to receive the frames for the 

next segment. 

5 Synchronization 

In DDE-1, triggers consists of a required URL, the required “tve” attribute which 

identifies the version of DDE-1 content to which the trigger conforms, optional name/value 

attributes (“name”, “expires”, “script”), and depending on the means of delivery, a checksum. 

The URL of the trigger identifies the topmost page, i.e., the root in DASE terminology, of the 

application. If the URL equals the URL of the root of the currently running application, then the 

trigger signals the running application; otherwise, the trigger may initiate a new application and 

must have a “name” attribute to be valid. The “expires” attribute indicates the time after which 

the trigger is no longer valid. The “script” attribute contains the script text to be executed upon 
 

receipt of the trigger. DDE-1 triggers deliver a single signal, i.e., a single script. The target of the 

script is the trigger’s URL, i.e., the root of the application. For details, see [DDE-1], appendix E. 

In DASE, triggers are the content type application/dase-trigger. Like all DASE content, 

triggers are delivered by means of the ATSC A/90 framework (see section 6). The DASE trigger 

mechanism is built upon the functionality of DOM-2 Events [DOM2-EVENTS]. A DASE 

trigger consists of several events of type “script”, i.e., a single DASE trigger can deliver several 

signals to an application. The target of the script event can be any URI identifying declarative 

content within the application, and can make use to the “bubbles” and “cancelable” features of 

DOM-2 Events. Each script event is invoked by means of the DOM-2 Events infrastructure. For 

details, see [DASE-DA], section 4.5. 

6 DDE-1 Content Delivery Compared to DASE 

DDE-1 specifies two types of interactive content delivery: Transport A, and Transport B. 

With Transport A, only triggers are delivered with the broadcast stream. Other primary content is 

actively acquired by the receiver by means of a backchannel, usually an Internet connection. 

DDE-1 specifies an interface that enables an enhancement to obtain information about the 

availability of a backchannel and whether it is currently connected. The URLs in DDE-1 

Transport A triggers identify the content to be fetched over the backchannel using HTTP Version 

1.1. 

With Transport B, all content, including triggers, are delivered by means of the broadcast 

stream. A backchannel may optionally be present for transactions or general Web browsing, but 

content for applications is delivered via the broadcast. DDE-1 Unidirectional Hypertext 

Transport Protocol (UHTTP) [DDE1-UHTTP] is the protocol used for content delivery in 

Transport B. The binding of application announcement metadata and UHTTP to IP Multicast is 

specified in DDE IP Multicast Encapsulation [DDE1-IPM]. The binding of DDE-1 content for 

both Transport A and Transport B to the NTSC video standard is specified in DDE-1 NTSC IP 

and Trigger Binding to VBI [DDE1-NTSC]. The binding of DDE-1 content for both Transport A 

and Transport B to the PAL/SECAM system is specified in DDE-1 TRIGGERS and IP Binding 

to PAL/SECAM SYSTEM [DDE1-PAL]. 

In DASE, all content is delivered in the broadcast stream according to ATSC A/90 

[ATSC-A90] and the Application Reference Model [ATSC-ARM]. Three types of information 

about an application are delivered: announcement, signaling, and content. Application 

announcement information indicates the future availability of an application, and consists of 

metadata about the application, such as, name, description, availability time and duration. 

Application signaling information indicates the imminent arrival of an application’s content, and 

includes the identification of the application’s root entity. Following application announcement 

and signaling information is the application’s content. Each content element is delivered with its 

identifier and content type. 

ATSC, in addition to more native generic resource carriage in A/90, also includes a 

specification for IP Multicast binding [ATSC-IPM]. Thus, with the A/90 and DDE-1 IP 

Multicast specifications, there is a standard way of broadcasting DDE-1 content with A/90. 

For more information about data broadcasting applications, specifically within the ATSC 

data framework, see [ATSC-DATA]. 
 

7 Example ITV Applications 

Figure 2: Educational ITV Application 

ITV applications range in complexity from the very simple to the very sophisticated. An 

example of a simple ITV application is one which offers the viewer a pizza delivery. This 

application could be synchronized with the broadcast of a sporting event or a commercial for the 

pizza retailer. This example illustrates a simple e-commerce application. It is an example of an 

ITV application designed for the functionality of the backchannel informatively defined in DDE1. The backchannel, an Internet connection or possibly some form of proprietary phone 

connection, is the means of completing the real-time transaction implied in this example. 

ITV applications can also provide a richer viewing experience. One such example is an 

application that provides the viewer the opportunity to interactively obtain additional information 

about a sporting event during the broadcast. Consider the broadcast of a golf tournament. The 

viewer is offered the opportunity to browse information about the score for the current player, 

the details of the current green, player statistics, and information about the tour. This application 

is an example of an application that can be designed for the functionality of either DDE-1 or 

DASE. This application requires neither backchannel nor high performance procedural 

environment. 

Figure 2 shows a sophisticated ITV application. It is an educational program for learning 

about constellations. Developed at NIST, it is an example of an ITV application designed for the 

functionality specified in DASE. In the application, a narrator first describes several 

constellations while the outline of the constellation is shown against the star field in the night 

sky. Then, the viewer is shown a picture of a constellation’s star field, and encouraged to draw 

the outline of the constellation on the star field shown. The current outline is then displayed 

along with the viewer’s drawing so that the viewer can compare. Figure 2 shows the narrator 

along with a viewer’s drawing (shaded lines) of the Big Dipper overlaid with the correct outline 

(straight white lines). This application requires local interactivity by the user with a pointing 

device, such as a mouse, and a high performance procedural application environment. Hence the 

need for a DASE-PA like system. 
 

8 Summary 

This paper summarized the SMPTE DDE-1 specifications and compared DDE-1 to 

DASE. In addition, this paper compared DDE-1 applications (“enhancements”) and DASE 

applications, and summarized the functionality specified within DDE-1 and DASE to enable 

content developers to present and manage ITV applications. This paper also gave examples of 

ITV applications. 

Acknowledgements 

The authors would like to thank Dr. Alan Mink and Mary Laamanen of NIST for their 

reviews of this paper.

9 References 

[ATSC] Advanced Television Systems Committee, http://www.atsc.org 

[ATSC-A90] ATSC Data Broadcast Standard, A/90, Advanced Television Systems Committee, 

26 July 2000 

[ATSC-ARM] ATSC Data Application Reference Model, ATSC ARM001R1, 17 Apr 2001 

[ATSC-DATA] Chernock, et al, “Data Broadcasting: Understanding the ATSC Data Broadcast 

Standard”, McGraw-Hill, 2001 

[ATSC-IPM] DELIVERY OF IP MULTICAST SESSIONS OVER ATSC DATA 

BROADCAST, ATSC T3/S13-012 

[ATVEF] Enhanced Content Specification, v1.1 r26, Advanced Television Enhancement Forum, 

http://www.atvef.com 

[BW70] Business Week, October 4, 1999 

[CSS1] Cascading Style Sheets, Level 1, W3C Recommendation 

[CSS2] Cascading Style Sheets, Level 2, W3C Recommendation 

DASE Documents: 

ftp://atsc:atsc1080i@ftp.atsc.org/S17/T3/

ftp://atsc:atsc1080i@ftp.atsc.org/S17/

[DASE] DASE Part 1: Introduction, Architecture, and Common Facilities, ATSC T3/528, 9 Feb 

2001 

[DASE-API] DASE Part 4: Application Programming Interfaces, ATSC T3/531 
 

[DASE-DA] DASE Part 2: Declarative Applications and Environment, ATSC T3/529, 9 Feb 

2001 

[DASE-CONF] DASE Part 8: Conformance Statement, ATSC T3/S17-xxx 

[DASE-FONT] DASE Part 5: Portable Font Resource, ATSC T3/532, 9 Feb 2001 

[DASE-PA] DASE Part 3: Procedural Applications and Environment, ATSC T3/530, 9 Feb 2001 

[DASE-SEC] DASE Part 6: Security, ATSC T3/S17-xxx 

DDE Documents: ftp://smpte.vwh.net/pub/d27/dde.htm

[DDE1] Declarative Data Essence, Content Level 1, SMPTE 363M 

[DDE1-DOM0] Document Object Model Level 0 (DOM-0) and Related Object Environment, 

SMPT Draft q, 15 March 2001 

[DDE1-IPM] Declarative Data Essence - IP Multicast Encapsulation, SMPTE 357M 

[DDE1-lid] The Local Identifier (lid:) URI Scheme for Referencing Locally Stored Content 

Resources, SMPTE Draft g, 18 Apr 2001 

[DDE1-NTSC] NTSC IP and Trigger Binding to VBI, DDE-1, SMPTE 361M 

[DDE1-PAL] TRIGGERS and IP Binding to PAL/SECAM SYSTEM, SMPTE Draft a, March 

2001 

[DDE1-UHTTP] Unidirectional Hypertext Transport Protocol, SMPTE 364M 

[DOM2-CORE] Document Object Model (DOM) Level 2 Core, W3C Recommendation 

[DOM2-EVENTS] Document Object Model (DOM) Level 2 Events, W3C Recommendation 

[DOM2-HTML] Document Object Model (DOM) Level 2 HTML, W3C Working Draft 

[DOM2-STYLE] Document Object Model (DOM) Level 2 Style, W3C Recommendation 

[DOM2-VIEWS] Document Object Model (DOM) Level 2 Views, W3C Recommendation 

[ES2] ISO 16262, ECMAScript Language Specification, 2ed Edition 

[ES3] ECMAScript Language Specification, 3rd Edition, ECMA 

NIST DASE Development Environment: 

http://www.itl.nist.gov/div895/cmr/dase/index.html
 

NIST DDE-1 Trigger Test Materials: 

Abstract Test Suite: http://xw2k.sdct.itl.nist.gov/koo/trigger/

Sample Tape Documentation: http://xw2k.sdct.itl.nist.gov/koo/test_suite/

Sample Tape Test Cases: http://xw2k.sdct.itl.nist.gov/koo/test_suite/sample_tape.htm

[SMPTE] Society of Motion Picture and Television Engineers, http://www.smpte.org 

[W3C] World Wide Web Consortium, http://www.w3.org 
Mass Customization of DASE Broadcast

and Increased Advertisement Capacity

Eddie Schwalb

Sharp Labs of America 

eschwalb@sharplabs.com

With the advent of the Internet. the value of customizing content to the individual preference of 

millions of viewers became apparent, as the major Internet players, e.g., Yahoo!, derive a significant portion 

of their revenue from such mass-customization capabilities.

The advent of Digital TV has enabled advances in the area of user selectable content used in

conjunction with traditional broadcast distribution. Unfortunately, existing DTV broadcasts still cannot be 

customized to the individual preferences of millions of TV watchers. In that respect, the multimedia

broadcasting industry in general, and terrestrial broadcasting in particular, is lagging behind the Internet 

(aka .com) industry.

We present a method for customizing a single uniform broadcast to fit the preferences of individual 

viewers. The unexpected result is an arbitrary simultaneous increase in the advertisement effectiveness and 

time capacity, both of which are critical revenue drivers for broadcasters. Further, this is achieved without 

impacting, but rather protecting, the privacy of viewers, as it does not require communicating the

preferences stored in the client back to the broadcasting server.

331
6/29/2001 Eddie Schwalb, Sharp Labs 

Mass Customization of DTV BroadcastEddie SchwalbSharp Labs of America
6/29/2001 Eddie Schwalb, Sharp Labs 

Introduction 

The Internet demonstrated the vacustomizing content to the individpreference of millions of viewersWhat is required to achieve the safor Digital TV?

! Can Direct Channel Change be used! Can DASE be used?
6/29/2001 Eddie Schwalb, Sharp Labs 

Outline

Broadcast Customization

! Transport Subsetting, Ad-Insertion! plugins, DCC, display switching, triggers

Ramification: 

! increased capacity! happier consumers

Roles

! content authors! advertisers! broadcasters! receivers

Summary

t

HAVi

plugins PA

PAE

DA

DAE 
6/29/2001 Eddie Schwalb, Sharp Labs 

Receiver

Transport Subsetting

Bringing 

customization 

closer to 

consumers

Broadcaster Broadcaster Uniform Decoder Decoder DASE

DCC 

controls

DCC 

controls

DASE 

controls

DASE 

controls

Renderer 

uses Prefs 

to subset

broadcast

Renderer 

uses Prefs 

to subset

broadcast

Displ

Displ

Displ

Displ

Displ

Displ

...

...

Customized CustomizedSubse

SubseSubse
6/29/2001 Eddie Schwalb, Sharp Labs 

Ad-Insertion

Static & Animated banner ads (PluDisplay Switching (Native | Java)Synchronization (Triggers)
6/29/2001 Eddie Schwalb, Sharp Labs 

DA Ad-Selection using Plug

<object classid="plugin.class“>

<ARG.0=“banner-ad.png“ />

</object>

Plugin code queries user preferences ‘org.atsc.preferences‘ and customizes 

accordingly.

Plugin classes

Ad Content

<Object> tag
6/29/2001 Eddie Schwalb, Sharp Labs 

DASE Synced Ad Display

Banner-Ad insertion at discontinuity point

Main Video

discontinuity

Advertisements ImagesAdvertisement Images

dis

Ad 

presentation 

interval discontinuity

Ad 

presentation 

interval
6/29/2001 Eddie Schwalb, Sharp Labs 

Time

STC

Trigger Model (S13 work-in-pro

Preload-Data PTS

target

discontinuity

~1 frame
6/29/2001 Eddie Schwalb, Sharp Labs 

Plugins can process Trigger

<object classid="plugin.class“>

<ARG.0=“banner-ad.png“ />

</object>

Plugin code can ‘listen’ for triggers via thTriggerAPI org.atsc.trigger.

Ad Content

Display

Triggers

Plugin classes
6/29/2001 Eddie Schwalb, Sharp Labs 

DASE Triggers (work-in-progres

Use Triggers to signal ad display:

AppID should be 0 to indicate ‘current’ servicPresentation Time Stamp (PTS) set to display Target contains reference to advertisement fiPayload contains ‘key-words’,’properties’ info

Main Display

Trigger 

PTS

Trigger 

PTS

Tri

P

AppID=0 PTS Target

Trigger

Props
6/29/2001 Eddie Schwalb, Sharp Labs 

DASE Triggers (work-in-progres

Use org.atsc.trigger.TriggerEvent:

getTarget() to get advertisement filesgetProperties() to get ‘key-words’Use org.atsc.preferences to compare ‘key-wo

Main Display

Trigger 

PTS

Trigger 

PTS

Tri

P

AppID=0 PTS Target

Trigger

Props
6/29/2001 Eddie Schwalb, Sharp Labs 

Direct Channel Change (why 

DCC selection utilizes geographic criter

but does not utilize individual preferenc

Virtual 

Channel 3

DCC selection Criteria ‘A’ 

DCC selection Criteria ‘B’ 

Virtual 

Channel 2

Virtual 

Channel 1

Virtual 

Channel 1
6/29/2001 Eddie Schwalb, Sharp Labs 

Display Switching

DASE improves on DCC

DASE enables applications to select vid

streams based on individual preferenc

Video 3

Preferences of viewer ‘A’

Preferences of viewer ‘B’

Video 2

Video 1 Video 1 continued
6/29/2001 Eddie Schwalb, Sharp Labs 

Tuning is performed via 

ServiceContextSelection

Tuning could be native or JavaJavaTV (or native emulation) enables decoupling of Services from their DisplNo ‘tuning’ APIService = Virtual Channel / Data ServicServiceContext = Display AreaServiceContextSelection 

! maps Service onto ServiceContext ! = indirect ‘tuning’ via selection

Selection Criteria: org.atsc.preferences
6/29/2001 Eddie Schwalb, Sharp Labs 

Advertisements

Advertisements

Main Video

DASE Synced Display Switc

Plugin could ‘switch’ streams 

at points of abrupt change

discontinuity

dis

Display 

switching 

interval discontinuity

Display 

switching 

interval

Bandwidth, bandwidth, bandwidth

...
6/29/2001 Eddie Schwalb, Sharp Labs 

Increased Capacity

Assumptions:

So

what?

So

what?

! Each commercial sequence has 

n slots.

! There are 

k alternatives for each slot.

Total number of possible sequences:

n

k = exponential increase in possibilities.

Each time slot:

! Can be shared among 

k commercials

! Each commercial is much better targeted! Value:

" Individual value may not decrease by factor 

k due to 

" Total value likely to increase having 

k-times more slo

Hypothesis: Capacity increased in proportion w
6/29/2001 Eddie Schwalb, Sharp Labs 

Happier Consumers

Consumers could ‘choose’ their commercials (not eliminate them)Unlike the Internet – private

So

what?

So

what?
6/29/2001 Eddie Schwalb, Sharp Labs 

Better than Internet

Customization is achieved with

receivers sending preferences emission stations

Without a return channel, it is 

possible to extract individual receiver preferences
6/29/2001 Eddie Schwalb, Sharp Labs 

Roles (simplified view)

Content Authors

Advertisers

Broadcasters Rec
6/29/2001 Eddie Schwalb, Sharp Labs 

Role of Content Authors

Should use triggers to mark comme

insertion points:

PTS should point to insertion pointsTarget & properties should be ‘empty’ hooks for broadcasters to insert commNumerous hooks should probably be inper-insertion-point
6/29/2001 Eddie Schwalb, Sharp Labs 

Role of Advertisers

For each advertisement generate:

key-words (trigger properties)PTSAggregated Target
6/29/2001 Eddie Schwalb, Sharp Labs 

Role of Broadcasters

Should minimally process triggers:

populate trigger with references to commercial filespopulate trigger with key-words
6/29/2001 Eddie Schwalb, Sharp Labs 

Role of Receivers

Need to be capable of:

collecting consumer’s preferencesmatching key words of preferencethose of trigger’s key words

! DASE applications are launched before PTS! Listeners are invoked at the PTS

switching display to the best matcvideo component

! DASE applications perform ServiceContext selectio
6/29/2001 Eddie Schwalb, Sharp Labs 

Architecture

DASE Content

(XHTML, CSS, ECMAScript, JavaTV Xlet, ...)

DASE Reciever

Common Content Decoders

(PNG, JPEG, TrueDoc Font, ...)

Security Framework

Procedural Application Environment

Java Byte Code Interpreter

(Java Virtual Machine)

pJava, JMF, JavaTV, HAVi, DAVIC, ATSC

API Implementation

Declarative Application Environment

ECMAScript

Interpreter

XHTML

Interpreter

Cascading

Stylesheet

Interpreter

Document and Environment Object Model

API Implementation

PSIP 

database

StreamParser

r

d

DASE Content [DASE]

(XHTML, CSS, ECMAScript, JavaTV Xlet, ...)

DASE Reciever

Common Content Decoders

(PNG, JPEG, TrueDoc Font, ...)

Security Framework

Procedural Application Environment

Java Byte Code Interpreter

(Java Virtual Machine)

pJava, JMF, JavaTV, HAVi, DAVIC, ATSC

API Implementation

Declarative Application Environment

ECMAScript

Interpreter

XHTML

Interpreter

Cascading

Stylesheet

Interpreter

Document and Environment Object Model

API Implementation

PSIP 

database

StreamParser

D

r

d

Transport Stream

[DASE-DA] [D

[A/65+A/90] [A

[DASE-SECURITY]

[A/65+A/90]

VCTDSD

Tuner

Switch logic
6/29/2001 Eddie Schwalb, Sharp Labs 

Summary

The promise of mass-customization could be transferred to broadcastinIt is possible to simultaneously 

! increase advertisement capacity, ! make consumers happier and 

DASE Triggers may be essentialRequires some degree of coordinat
6/29/2001 Eddie Schwalb, Sharp Labs 

Where to Get More Information

S17: The DASE specificationsS13: Data Broadcast specifications S18: Application Reference Model 
Comprehensive Public Key Infrastructures and 

the Realm of DASE Security

Edwin Heredia

Microsoft Corporation 

1065 La Avenida, 

SVC 3, Mountain View, CA 94043 

eheredia@rnicrosoft.com

With the introduction of downloadable code in digital television -a media that can potentially reach 

millions of users simultaneously- comes the risk of spreading malicious code. The response is the

deployment of a Public Key Infrastructure (PKI) that unfortunately cannot guarantee safety (it is extremely 

hard to determine if a piece of code is malicious or not) but at least, it establishes spread prevention, trust 

chains and, most importantly, legal bindings.

The objective of this presentation is twofold: first it will explain all (or most) of the components that 

are believed nowadays to be part of an overall comprehensive Public Key Infrastructure (PKI), and second 

we will offer a comparative analysis of the DASE security components against this comprehensive PKI. To 

offer a better perspective, we will include comparisons with other deployed PKI-based security

architectures.

Full implementation of an end-to-end Public Key Infrastructure (PKI) requires agreed standards, 

certification authorities, structures among multiple certification authorities, methods to discover and to

validate certification paths, certificate distributions, CRL distributions, management protocols for on-line 

and off-line interaction of PKI components, interoperable tools, provisions for certification, initialization,

certification, revocation, recovery, and last but not least, supporting legislation. Implementation of all of 

these components would result in an overall comprehensive PKI that exists only conceptually but it is 

expected that practical implementations will approach this model in incremental steps.

Table 1 illustrates a selected list of comprehensive PKI elements. Because DASE-1 concentrates on 

a channel that starts at the emitter or broadcast station and ends at the decoder, the channel is considered 

relatively secure. However, if the server at the emitter becomes a gateway, or when a return channel is 

incorporated in the architecture, then an interoperable security model based on a PKI becomes necessary.

347

Table 1. Elements of a comprehensive PKI

Certification Authority Certification Repository Certification Revocation

Key Backup Key Recovery Automatic Key Update

Key History Management Cross-Certification Client software

Authentication Integrity Confidentiality

Secure Time Stamping Notarization Non-repudiation

Secure Data Archive Privilege/Policy Creation Privilege/Policy Verification
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

A Comprehensive Public-Key Infrastand the realm or DASE security

A Comprehensive Public-Key Infrastand the realm or DASE security

Edwin HerediaMicrosoft CorporationSilicon Valley Campus, Bldg 1065 La Avenida,Mountain View, CA 94043
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

PKI f

PKI f

Basic PKI objectives

! Endpoint Authentication! Message Integrity! Confidentiality

Additionally, a PKI provides

! Spread prevention of unsafe code! Trust models that depend on registered authorities! Legal bindings through digital signatures

These functions are implemented using public-key cryptogra

thus the name of Public-Key Infrastructure (PKI).

It is extremely difficult to the safety of downloadabmost we can provide secuminimize the problem anchain of trust for legal bi
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Threa

Threa

!What resources we expect an attacker to have available?!Every security system is vulnerable to one threat or another!What attacks are we going to worry about?!What attacks we are NOT going to worry about?!Protecting against attacks where one of the end systems is undecontrol of the attacker is extraordinary difficult!An active attack is when the attacker writes/modifies content. Apassive attack merely involves reading data from the network.!Usually we do not worry about denial-of-service attacks, not bthey are not important, but because they are very difficult to prot!Security should not become more expensive than what it is wo
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Cryptographic A

Cryptographic A

Message DES-MAC, HMACauthentication

RSA, DSS (based on RSA, DSA or EC-DSA)

Digital signatureKey establishment RSA, Diffie-HellmanDigest algorithms MD-5, SHA-1

RC2, RC4, RC5, DES, 3DES, IDEA, AES

Symmetric encryption
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

PKI cryp

PKI cryp

encryption encryption decryption

AA decryption

encryption encryption decryption

A decryption

A

Bob’s public key Bob’s private key

Alice’s private key Alice’s public key

Confidentiality

Authentication
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

DTV Infras

DTV Infra

client client

Content Content

E

E

c

cl

Distribution 

Network

LAN/WAN/Internet

Remote

servers

Remote

server
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Public Key Infra

Public Key Infra

Alice Alice

Intranet 

CRL r

Certificate Repository

C.A. C.A.

"Registers Alice in a database and verifies her identity."Creates a Private-Public key pair. Private key goes to Alice (and should be stored carefully). Public key goes to a certificate."A certificate is like a driver’s license for Alice. It has her identity plus her public key. Message

Hash &Signature

Certificates

CA, A, 

"

CA, A, 

"

•Verifies tsignature i•Checks ex•Checks re•Verifies A•Trusts the 

CA, CA, 

"

CA, CA, 

"
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Roles and Respo

Roles and Respo

CA Responsibilities

•Use a trustworthy system and provide a secure environment•Disclose practices and procedures•Properly identify certificate applicants•Publish issued certificates•Revoke certificates•Make warranties to the certificate applicant upon issuance of thcertificate•Make warranties to persons using the certificate to verify digitsigned messages

Subscriber Responsibilities

•Make truthful representations in applying for a certificate•Review and accept certificates before using them•Make certain representations upon acceptance of the certificate•Control and keep confidential the private key•Report key compromise as soon as it happens
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Elements of a comprehensive 

Elements of a comprehensive 

Automatic key no no yes nupdateKey recovery no no yes nKey backup no yes yes nCertificate no yes yes

2

revocationCertificate no no yes

2

repositoryCertificate yes yes yes

2

authority

Element Internet SSL client Intranet DA
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Elements of a comprehensive 

Elements of a comprehensive 

Confidentiality yes yes yes

2

Integrity yes yes yes

2

Authentication yes yes yes

2

Client software no no yes

2

Cross- no no no

2

certificationKey history no no yes nmanagement

Element Internet SSL client Intranet DA
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Elements of a comprehensive 

Elements of a comprehensive 

Privilege/policy no yes no nverificationPrivilege/policy no yes no

2

creationData archives no no no nNon- partial partial partial parrepudiationNotarization no no no nSecure time no no no nstamping

Element Internet SSL client Intranet DA
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Broadcast Transpo

Broadcast Transpo

Transport

Stream

VC 1 VC 1VC 2 VC 2VC 3 VC 3

VC X VC XVC Y VC Y

VC Z VC Z

data event 1 data event 1 data event 2 data event 2

data event 3 data event 3 da

da

data 

data 

CA, A,

"

data event 5 data event 5

CRL services

CA, A, 

"

CA, A, 

"

CA, A, 

"
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

SSL/TLS as a model for Return Channe

SSL/TLS as a model for Return Channe

client client

Supported ciphers, Random value

Chosen cipher, Random value,

Certificate(s)

Encrypted pre-master secret

Compute keys Compute keys

MAC of handshake messages

MAC of handshake messages
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ce

Ce

♣ Based on X.509 v3 standard♣ Serves as the legal binding between a subject and its public key♣ Issued by a legal certificate authority that must verify and registeidentity of the subject.♣ Certificates include a lifetime period.♣ The issuer needs to digitally sign the certificate. ♣ If the issuer is not a root CA, it needs to provide extra certificates with the established root CA.♣ Other important fields include the subject’s alternative name, the this key, CRL distribution points, certificate policies, and others.♣ May be delivered with the application or stored in a repository
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Certificate Revoca

Certificate Revoca

♣Used to revoke a certificate before its expiration.♣A CRL is a list of certificate serial numbers.♣Typically updated every few weeks (this period depends on how sinformation is). ♣Under strict control and ownership of the C.A. - The lists are signC.A. - Repositories are maintained (and secured) by the C.A.♣Syntax and Semantics defined in X.509 v.2.

#CRL common fields (version, signature, issuer, this/next update).#Certificate entries and entry extensions.#CRL extensions.

♣“Next Update” field in CRL may be used by hosts (or STBs) to calatest release at the proper time.♣A multicast/broadcast channel is a perfect distribution method for However, they are normally accessed on demand. They may be acctime.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Standards tha

Standards tha

Provides a multimedia platform with smethod to authenticate and check inte

DVBS/MIME Provides a standard for secure e-mail

Provides a symmetric key-based framelarge networks.

Kerberos V5IPsec Defines transparent encryption for net

Provides a secure and authenticated chbetween hosts and the Internet above tlayer.

TLS/SSL

De facto standards for public-key mesexchange.

PKCS

A working group for IETF that designinteroperable PKIs for the Internet

PKIX
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

http://www.microsoft.com/T

http://www.microsoft.com/T

Tha

Tha
Aggregating DASE Applications

Eddie Schwalb

Sharp Labs of America 

eschwalb@sharplabs.com

When authoring DASE content, applications need to be packaged within data services. However, such 

packaging requires tight coordination and collaboration between content producers and content aggregators. 

Key issues include the distribution of applications among data services, URI mappings, integration of 

triggers and startup Gill integration. We explore some issues that need to be addressed in order to enable 

content-producers to pre -package broadcast-ready (i.e., shrink-wrap) applications.

We present a framework of requirements with which compliance enables the decoupling of content 

producers from aggregators, and allows aggregators to transfer data to emission stations without tight 

coordination. We suggest that the packaging should be in a format that could be automatically analyzed and 

placed on ATSC-compliant transmission systems. Methods are presented on which content-producers can 

rely when authoring applications, content-aggregators can rely when compiling data services, and content 

emitters can rely on when emitting content to be viewed by millions of viewers. The requirements are 

presented in the form of constraints on the structure and content applications.

The distribution of applications within data services involves tradeoffs between bandwidth and

accessibility. Aggregating all applications into a single data services renders them all available without the 

need for broadcasters to maintain consistency of multiple related data services and without the need for 

receivers to switch data services (requires special permission) when switching applications. However, the 

use of carousels implies that as their size becomes large enough, the response time of receivers

(downloading these carousels) becomes prohibitively slow.

Application resources are associated with URIs, which need to be embedded within the transport 

stream in appropriate locations, e.g., either DST or NRT. An automated procedure is needed, that analyzes 

applications and generates the transport binding for the URIs used in all inter-related applications. While 

this problem is manageable for Declarative Applications (DA), it much more difficult for Procedural

Applications (PA). To solve this problem, additional mapping information needs to be shipped with the PA 

to the aggregator.

Integration of triggers is a complex issue. The transport layer defines lightweight triggers that, instead 

of carrying much data or code, carry pointers to the relevant data and code. In contrast, DASE requires the 

use of heavyweight triggers that carry both data and code. This difference implies the need for a packaging 

phase, in which heavyweight DASE triggers, generated by content-authors, are translated into lightweight 

transportable triggers.

The data service startup Gill application could serve as a dispatching application which is the target for 

Gill events and triggers. Because DASE-l allows a single application to execute at any given time, an 

inevitable challenge is managing application switching. While solving this problem, we uncovered a number 

of constraints and structures that need to be imposed on content producing tools, to be used by contentproducers and aggregators alike.

359
6/29/2001 Eddie Schwalb, Sharp Labs 

Aggregating DASE Applicat

Eddie SchwalbSharp Labs of America
6/29/2001 Eddie Schwalb, Sharp Labs 

Introduction 

DASE Application must go through long process until they reach a consumerVarious aggregation tasks are pres

! The aggregation model! URI mapping tasks! Meta-data usage! Dispatching application ! Bandwidth considerations
6/29/2001 Eddie Schwalb, Sharp Labs 

Overview 

The ATSC standard defines how applications are structured and placed in a transport stream.Impacted are authors, aggregators, broadcasters and receiver manufacturers.

aggr

hend brcast

studios

aggr

studios 
6/29/2001 Eddie Schwalb, Sharp Labs 

Context ‘food-chain’

Studios Studios Ad agencie

Ad agencie

Aggregators Aggregators

Receivers Receivers

Broadcasters Broadcasters
6/29/2001 Eddie Schwalb, Sharp Labs 

Step 4

Step 3

Physical Channel 3Physical Channel 2Physical Channel 4Physic al Channel 1

The Aggregation Model

ModuleModuleModuleModuleModule

Step 1

Application2Application1

Step 2

Data Service 2 / Virtual Channel 2Data Service 3 / Virtual Channel 3Data Service 1 / Virtual Channel 1
6/29/2001 Eddie Schwalb, Sharp Labs 

The aggregation Problem

Aggregate: 

modules (code+data) into applicationsapplications into data services (virtual cdata services into major channels & tra

... each of these steps requires some 

manipulation of content
6/29/2001 Eddie Schwalb, Sharp Labs 

ATSC Impact

Studios & Add Agencies:

! Defines content specifications

" XDML is used to author DTV-pages" JavaTV and org.atsc API used for active 

Aggregators:

! defines an aggregation model

" URI name spaces" Relationships between modules and tran

Broadcasters:

! Defines the transport specifications

" uses A90 to define transport-layer" uses ARM for an application reference m

Receiver manufacturers:

! Defines receiver behavior

" receiver architecture" behavior of execution environments
6/29/2001 Eddie Schwalb, Sharp Labs 

URI usage (studios)

Modules are assigned a lid URI at autholids of modules are aggregated in each sform a complete application and data service/virtual channel hierarchylids should be unique to avoid collisionslids should not include transport-layer configuration: lid://transport/channel/service/application/mod
6/29/2001 Eddie Schwalb, Sharp Labs 

URI extraction 

(studios, ad-agencies & aggregato

Applications comprise of

! Resources (data-essence)! URIs (meta-data)

Aggregators could extract URIs from static refmade by DAIt is not possible to extract URIs generated by dynamic ECMA Script or Java code.Both studios and ad-agencies need to attach tcontent application an exhaustive list of URIs tto be placed in a program by the aggregators.All that is really needed is management of bas
6/29/2001 Eddie Schwalb, Sharp Labs 

Aggregating Files

Preserve names given by 

original content auth

Binding Structure Binding Structure

objectInfo objectInfo

name name

Directory Object Directory Object

directory file
6/29/2001 Eddie Schwalb, Sharp Labs 

URI transmission (aggrega

(S13 TSFS work in progress)

cache directives base-URIs 

Binding structure 

objectInfo 

name

Directory object 

owner identifiersaccess attributes 
6/29/2001 Eddie Schwalb, Sharp Labs 

URI transmission (aggrega

(S13 TSFS work in progress)

File object 

objectInfo 

base-URI content-type cache directivestime-stampowner itentifiers size 
6/29/2001 Eddie Schwalb, Sharp Labs 

Decoupling of Name Space

Object Carousel Hie

URI Hierarchy

URI Hierarchy

URI Hierarchy
6/29/2001 Eddie Schwalb, Sharp Labs 

URI resolution (receivers)

Input: URI Output: TS download parameters –

carousel_id, transaction_id, module_id, vers

object_key

Requires traversing the directory objecCan be done completely ‘under-the-hothe TSFS

! avoid using transport-access API
6/29/2001 Eddie Schwalb, Sharp Labs 

Application Root Resource

Contains meta-data about the appl

! Info about authors! Info required by execution environme! Capability hints ! Functionality hints! Cache information! Certificates & security info (future)! PVR hints
6/29/2001 Eddie Schwalb, Sharp Labs 

Capability Hints

CPU class Mix requiremIWS sizeCache size# Decoders# TunersGraphic ResolutionColor Space

Input deviceBuffer modeReturn chanSecurityWeb-AccessFinancial Tra

Printing Export
6/29/2001 Eddie Schwalb, Sharp Labs 

Functionality Hints

change minor channel video scaling change major channel active object execution scripting execution display active area display inactive area 

audio mix/alteuser/config dauser/config dareturn channeprinting & othe
6/29/2001 Eddie Schwalb, Sharp Labs 

Preparation of Meta-Data

Distributor Information Program-RelatedVideo-RelatedAudio-RelatedData-Related
6/29/2001 Eddie Schwalb, Sharp Labs 

Data Service Meta Data

Data Service Announcement (EPGData Service SignalingApplication Signaling (Root ResourceTap SignalingCarousel SignalingEncapsulation Signaling
ANC Data, Metadata and Data Essence Standards

Mole Comp

329M

292M (1.485 G) 259M (270, 360) 34

Mapping

349M

Payload ID

352M

274M

1080

296M

720P

125M

480I 4:3

267M

480I

294M

Image Format

ANC Data Space

Serial Transport

HD ANC Audio

299M

SD ANC

Audio 272M

PCM Audio AES-3

KLV Encoding 336M

Metadata Dict. Structure 335M

Metadata Dictionary RP-210

ANC Data Formatting SMPTE 291M

UMID 330MUMID Apps RP-205

UPID TBD

N26.013

ANC Metadata

N26.014

SAR

KLV in AES-3 355M

HD-SDTI

348M

SDTI

305.2M

EDH

RP-165

Film Xfer Info

I23.005

ANC TC

RP-188

Edge

Code

RP-20

HANC TC

RP-196

Mole Data

327M

ANC Mole

353M

Camera Positioning Data

315M

ISAN ISO 15706

DVITC

266M

Time

Code

12M

Universal Labels 298M

William C. Miller, TV
6/29/2001 Eddie Schwalb, Sharp Labs 

Resource Description Framework 

http://www.w3.org/TR/REC-rdf-syntax/

Instead of asking machines to understand peask people to provide information that machiuse understand in order to achieve automatioGeneric end-to-end meta-data solution 

! Content description

" title, copyright, reviews, etc.

! Workflow annotations

" Each step-wise relation has its own 

! name space, format, security, etc.

" Supports check-lists, containers, alternatives, 

statements about statements.

Requires one additional small file transmitted the application
6/29/2001 Eddie Schwalb, Sharp Labs 

Dispatchers (aggregator

Generate menusMay be generated using ‘story-boards’ or scriptsCan be used to integrate ‘ad-apps’.

Dispatching Application

Content 

Applicatio

Commercial

C

C

Content 

Application

Content 

Application

Commercial

Commercial

Commerci
6/29/2001 Eddie Schwalb, Sharp Labs 

Triggers Transmitted in the Transport 

Application Replacemen

(DA dispatches DAs, PAs)

Commercials

Content 

Application

The single application executed at every given time point.

Dispatching Application
6/29/2001 Eddie Schwalb, Sharp Labs 

Bandwidth Requirements (broadca

The total transport stream bandwidth is 19.2mbps.

Each Data Service Table (DST) is transmitted twice per 

Applications should start up within 3 seconds of channe

Applications should start up within 3 seconds of channe

Application should respond to selection within 5 secondNo data should require more than 10 minutes to downldone overnight.

All DSTs and NRTs are allowed up to 6.66% overhead odata bandwidth.
6/29/2001 Eddie Schwalb, Sharp Labs 

Bandwidth Assumptions (broadc

About 10% of bandwidth will be allocated to services, i.e., about 5·G1.

All DSTs and NRTs are allocated 128kbps (=1=6.66% of 5·G1 overhead.

At most 4 data services will be aggregated wsingle transport stream.

At most 4 application will be aggregated withsingle transport stream.

On the average, first user selection is about 1seconds after application startup.
6/29/2001 Eddie Schwalb, Sharp Labs 

Reducing Carousel Average Acces

Simple technique for 

reducing maximum download period 

M 1. M 1.

11 M 1. M 1.

22 M 1. M 1.

11 M 1. M 1.

33

M 2. M 2.

11 M 2. M 2.

22 M 2. M 2.

11 M 2. M 2.

33

M 3. M 3.

11 M 3. M 3.

22 M 3. M 3.

11 M 3. M 3.

33
6/29/2001 Eddie Schwalb, Sharp Labs 

Bandwidth Pyramid 

(authors, aggregators)

DST, 4KB, 1/3 G1, 0.5sec

Legend: data_set, size, bandwidth, repeat duration.

DST = Data Service Table

IWS = Initial Working Set

D = Data (or code or both)

OTD = Off Transport Data (Internet)

IWS, 96KB, 2.66·G1, 3sec

D, 2.8MB, 2·G1, 30sec

OTD,

100MB,

5·G1, 7min

App#1

2MB

App#2

2MB

App

2M

Shared Data

3.25MB

Possible to resell data bandwidth without delivering data services.

Possible to use a return-channel or OOB channel to access files.

Authors should can IWS, and aggshould separate iother data
6/29/2001 Eddie Schwalb, Sharp Labs 

Transport Layer Configurat

All non-shared 

data required 

outside the 

initial set 

App#1 App#2 App#3 App#4 

Init data Init data Init data Init data 

Shared 

large

data 

50MB 

Transport 

Stream #1 

• Transport 

Stream #3 

• Out Of Band

• Internet 

(return channel) 

All non-shared 

data required 

outside the 

initial set 

App#1 App#2 

Init data Init data 

Shared 

large

data 

50MB 

Off 

Transport 

Data 

96KB 96KB 

Initial working 

set required to 

show the 

‘flash’ screen.

2MB 

data 

2MB

data 

96KB 96KB 96KB 96KB 

2MB 

data 

2MB

data 

2MB 

data 

2MB

data 

Initial working 

set required to 

show the 

‘flash’ screen. 

Shared 

data 

3.25MB
6/29/2001 Eddie Schwalb, Sharp Labs 

Summary

Touched on a wide-range of issues:

! Aggregation model! URI mapping! Meta-data usage! Bandwidth considerations

Aggregating applications requires numtypes of expertiseVarious types of processing of content be required
Integration of a RETE-Based Rule Engine 

into the DASE Environment 

Pourya M. Dehnadi 

Apex Logic, Inc. 

Washington DC, 20007 

pourya@apexlogic.com 

Much of the operations of a set-top device are dependent on the data that it receives from streams

such as the ATSC input stream. The procedural logic residing on the set top device is then able to access the

data, perform certain operations, and if appropriate, notify the viewer of any consequences. This data can

include PSIP information as well as data that are specific to an in-band or out-of-band application. Due to

the data-driven nature of the interactions that can take place between a viewer and a set-top device the

integration of a RETE based rule engine can increase performance and provide flexibility for the viewer and

the broadcaster. A RETE based rule engine uses a working memory and a set of rules. Each rule is in the

form of a material implication. These rules are contained in a rule set, however they are unordered, therefore

the correctness of one rule will not impact the performance of other rules. Each viewer can then, through an

interface, create a personalized viewing experience based on the rule set that she has created. Multiple rule

sets can exist for multiple members of a household. Rule sets can also be uploaded or downloaded allowing

for mobility. 

Rule sets can be authored, packaged, and transmitted to viewers by the broadcaster. This allows the

broadcaster the ability to leverage logic without having to write procedural code, since each rule can be

viewed as a declarative unit of operation. The rules can be generated by the broadcaster and downloaded

onto the set top devices by the MSO. Since the nature of interactivity over DTV is a push model, as

broadcast data is asserted into the working memory of the rule engine, immediate action is taken to fire rules

that have antecedents that match current data. Therefore PSIP, in-band, and out-of-band data alike can

trigger actions to be performed by the set top device in real time. 

The rule engine continually monitors the working memory (by means of the RETE algorithm) for

elements that match the antecedents of the rules. If a match is made then the rule engine fires the imperative

stated in the consequent of the matched rule. That imperative can be either the assertion of more data into

working memory (in the case of forward chaining) or it can be any Java API. By being able to invoke any

Java API the entire API's exposed to applications (such as DASE applications) are also exposed to the rule

engine. 

From an architectural standpoint, the rule engine is integrated into the DASE environment as a

DASE-compliant application. This provides for loose coupling between the application and the DASE

reference architecture and simplifies implementation. At an implementation level the compiled libraries are

relatively small and require minimal memory to run. 

Future work will include the development of a parameterized rule engine for the set top box as well

as an authoring tool to enable content developers to generate rules in a declarative mode. 

377
Apex Logic Proprietary 2001

Integration of a RETE-basedRules Engine into DASEPourya M. DehnadiDASE 2001 Symposium
Apex Logic Proprietary 2001

Overview! Data Overview! Rules: Using Data for Control! RETE algorithm and Rules Engines! Applications! Authoring and Distribution! Integration with the NIST RI! Next Steps! Conclusions
Apex Logic Proprietary 2001

Data Capture!ATSC stream

!Parsed into 3 Components

!Video – routed to DTV!Audio – routed to DTV!Data – routed to HAL

!DASE is concerned with the DATA 

portion of the ATSC stream
Apex Logic Proprietary 2001

Data Flow

ATSC 

Parser

STB 

Classes*

HAL 

Objects

API 

Objects

DASE 

Applicatio

Objects

* In the case of NIST RI
Apex Logic Proprietary 2001

Kinds of Data!PSIP Information

!Program type: Movie, News, Sports, e!Ratings: PG, R, TV-14, etc.!Content: Actor’s name, Summary, etc

!In-band Applications

!Sport Surveys

!Out-of-band Applications

!Messenger!Stock Ticker
Apex Logic Proprietary 2001

Rules and DASE: Data as Cont!Rules will allow us to leverage the 

that we are already collecting, to inactions, thus obtaining control.

!Rules can be created by content 

developers, broadcasters, and view
Apex Logic Proprietary 2001

Brief History of Rules

Rules have resurfaced; Forgy has built RE100 times faster than the original.

Today

Distributed Computing, Cheaper RAM, fastprocessors spark life in Rules.

Mid ‘90s

Rules have failed, deemed to be expensive run and maintain.

Early ‘90s

“Gang of Four” companies, destined to suc– BusinessWeek; NASA develops CLIPS.

‘83 – ‘90

John McDermott and DEC develop R1/XCOsaving DEC millions in manufacturing.

‘81‘70s Charles Forgy publishes the RETE algorith
Apex Logic Proprietary 2001

What are Rules?! Rules are Material Implications

! “if <antecedent> then <consequent>”! The antecedent is a declarative sentence! The consequent is an imperative sentence

A rule:

If it is raining, then bring an umbrella

Not a rule:

If it is raining, then it is overcast.
Apex Logic Proprietary 2001

Rule EngineComponents of a rule engine:

! Rules and rule sets! Working memory! Conflict sets

“Instantiation”

! A set of rules and the data in working memor

satisfy these rules

“Conflict set”

! Set of all instantiations at a given point in tim
Apex Logic Proprietary 2001

RETE Algorithm!Uses a Directed Acyclic Graph to cr

a network that is used to examine data in working memory against thantecedents of the rules in the rule sets.

!Increases performance, but require

RAM.

!RETE means Network in Latin
Apex Logic Proprietary 2001

RETE Algorithm1. Facts (objects and data) are asserted in

Working Memory (WME).

2. Rule Engine monitors WME for data tha

match the antecedent of rules.

3. Instantiations are created.4. More than one instantiation, results in a 

conflict set.

5. Conflict resolution is performed.6. The remaining instantiation is used to “

the consequent of the rules.
Apex Logic Proprietary 2001

Benefits of Rules and RETE!Unordered rules.!Independence of rules from each o!Faster Execution.!Small units of logic.!Procedures can be created through 

forward chaining.

!Backward chaining allows for goaldriven approach... like SQL.
Apex Logic Proprietary 2001

Data Flow, revisited

ATSC 

Parser

STB 

Classes*

HAL 

Objects

API 

Objects

DASE 

Applicatio

Objects

* In the case of NIST RI

Working 

Memory Rule Sets Rule Sets Rule Sets

Rule Engine
Apex Logic Proprietary 2001

Applications!Viewer Developed Rules

!Parental control:

!If rating is TV-MA or R, then switch to 

Nickelodeon.

!Personalized subsets of EPG:

!Display only sports shows or movies starri

Sean Connery.(If the program is a movie starring Sean Cor a sports show, then display it.)
Apex Logic Proprietary 2001

Applications! Content Provider or Broadcaster Develop

! In-band:

!If a viewer has tuned into the middle of the pro

then display a summary of what has happened 

! Out-of-band:

!If the viewer is a sports fan, then show scores 

ticker.

!If the viewer is an investor, then show stocks o

ticker.

!Else, show news headlines on the ticker.
Apex Logic Proprietary 2001

Futuristic Applications!Intelligent media selection based u

viewer profile.

!Example:

!Viewer Profile indicates male, 28, outd

activities. The STB could receive two commercials, one for cosmetic produc(default) and another for mountain-biThis viewer would see the mountain-bcommercial.
Apex Logic Proprietary 2001

Authoring!Viewer authoring must be mitigate

through a “wizard” like interface thwill ensure that rules are correct.

!Content developers may use a mor

sophisticated “drag and drop” interwith some scripting where necessa

!Depending on the implementation 

the rule engine, rules can be interpreted or compiled.
Apex Logic Proprietary 2001

Distribution!Applies to Content Developers, 

Broadcasters, and Viewers.

!Ideally, the rule engine will interpr

rules.

!Rule sets can be represented as te

based formats, such as XML.

!Rule sets can be transferred over I!Rule sets can be deployed remotely
Apex Logic Proprietary 2001

Integration with the NIST RI

Simulation 

Classes

DASE API

DASE App Rule E

HAL Java 

pJava

Streams

STB 

Control

The Rule Engine integrates as a DASE application
Apex Logic Proprietary 2001

Next Steps!Development of an authoring inter!Development of a standard file form

for distribution.

!Compliance with the privacy issues 

outlined by the Cable Act and otheregulations.

!Optimizations for the set-top box, 

as memory footprint (currently, thruntime jar is under 200Kb).
Apex Logic Proprietary 2001

Summary! Integration of a Rule Engine into DASE allows the 

data for control.

! Viewers, Content Developers, and Broadcaster ca

author rules given an authoring environment.

! Benefit of rules-based programming over proced

the decoupling of rules from one another, thus afor greater flexibility and availability.

! RETE algorithm provides improved performance 

non-RETE rule engines.

! Rule Engine integration with DASE is seamless, s

the Rule Engine shall be implemented as a DASE application.