2 000 NarroNAL Canr,n Tnr,sVISIoNAqqq C IATIOIi
`TECHI{ICAL PAPERS
`
`49th Annual NCTA Convention
`and International ExPosition
`New Orleans, LA
`MaY 7 -LO, 2000
`
`Netflix v. VideoLabs
`IPR2023-00628
`Netflix. Ex. 1024
`
`

`

`PROCBEDINGS FROM TEN TECHI{ICAL SESSIONS
`
`BA
`
`oo
`
`o
`
`MAY 7 - 10,2000. NEW ORLEANS, LOUISIANA
`
`49TH AIYNUAL CONVENTION AND
`INTERNATIONAL EXPOSITION OF THE
`NATIONAL CABLE TELEVISION ASSOCIATION
`
`Compiled by: Mark Bell, Director, Administrative Services, Industry AffairslAdministration
`Crysta Greenfield, Administrative Assistant, Science & Technology
`Joan Phelan, Assistant Director, Industry Affairs/Administration
`
`Published UV @ NCTA, the National Cable Television Association.
`rsBN # 0-940272-28-8
`
`Audio recordings for each session are available for purchase. Check your program guide for
`details May 7 - 10 and thereafter phone NCTA'S Industry Affairs department for details.202-
`1'15-3669. For availability and price information on a ten-year (1989-98) compilation of NCTA
`Technical Papers on CD-ROM, call NCTA'S Science & Technology department, 202-775-3637.
`
`

`

`The Challenge of a Standard Software API
`
`Mark Eyer
`Sony Electronics
`
`Cable Multiple-System Operators (MSOI)
`would like to supply not only digital audio, video,
`and data services, but also sofatare applications
`that can run on customer-owned equipment. With
`this goal in mind, CableLabs@ issued a Requestfor
`Proposal in 1999 to help identify and standardize a
`soffiuare Application Program Intedace (API) for
`OpenCable compliant retail boxes. This paper
`explores the challenges involved in this efort, and
`identifies some of the pitfalls and obstacles that
`must be overcome. These include issaes of
`platform independence, the cost and complexity of
`the platform, the challenge to support an evolving
`digital world, and the need on the part of consumer
`electronics manufacturers to dffirentiate their
`products in the markeplace. Suggestions for
`resolution of some of these dilemmas are presented
`for consideration.
`
`THE MSO'S VISION
`
`The eventual availability in the retail market of
`digital cable-compatible consumer devices offers
`the cable MSO a number of significant benefits.
`Whenever a customer buys a retail cable'ready
`device, the operator's capital expense is reduced.
`Due to competitive market pressures, the retail
`devices will be able to offer the latest technologies,
`including faster CPU speeds, ever-speedier
`graphics, and interfaces to the newest audio/video
`peripherals. And happier customers can result:
`rnany are more content without the need for the
`bulk and clutter of the set-top box, as set-top box
`functions are integrated with the digital television.
`This picture is quite clear for services including
`standard- and high-definition audio/video offered
`on subscription and impulse-pay-per-view (IPPV)
`basis. The standardization of the interface to the
`removable security moduleo the network (physical
`cable) interface, and system and service
`information (and agreements to deliver it) has
`enabled consumer electronics manufacturers to
`
`start designing digital cable-compatible devices for
`retail sale, starting with digital TVs (DTV).
`But what about other services, such a-\
`Electronic Program Guides (EPGs), video on
`demand (VOD), voice over IP (VOIP), or
`streaming audio and video in forrnats other than
`MPEG-2 or Dolby Digital? And what about
`services not yet conceived? Set-top boxes supplied
`by the MSO can be built to offer advanced
`services. How can a device available for retail sale
`be enabled to do so?
`A simplistic view of the world, from the point of
`view of the cable operator, is that the primary
`purpose ofany cable-ready device to be available at
`retail should be to generate revenue for that
`operator. To that end, the retail device would be
`100% controlled by the cable operator in terms of
`everything that is presented for viewing*its "look
`and feel."
`An MSO's drearn, therefore, might be that a
`DTV or other retail cable-ready device, after being
`brought home and installed by the consumer, would
`be downloaded with code supplied by the local
`cable operator. At that point, any access the
`consumer would attempt to make of any services
`offered on the cable would be managed through a
`navigation application supplied by the cable
`operator.
`If a special offer or preview were available, the
`navigator could make sure to present that
`information to the user. If new services were
`offered, the navigator could be set up to notif the
`user of their existence, and to guide the user
`towards their access. As an additional source of
`revenue, advertising or links to commercial sites
`could be included in the navigator.
`Services such as VOD could be offered because
`the navigator could support whatever proprietary
`form of access and control was required by that
`operator's plant and equipment. New forrns of
`services could be offered when they became
`available, even if the details of presentation ani
`
`2000 NCTA Technical Papers - page 242
`
`

`

`decoding are yet unknown. That's because an
`updated navigator could be provided when the
`details of the new service are worked out.
`An example of such a new service is a data
`broadcasting service. Multicast data synchronized
`to video is offered today, but the standardized
`techniques for transport and the content coding
`formats are not yet totally settled' When industry
`acceptance is widespread and the particular cable
`operator implements the new standard, the
`navigator can be upgraded to allow all subscribers
`to have access to the new data enhancement.
`The EPG can adapt the presentation based on
`what services are authorized for viewing in this
`particular device. For example, if the user has not
`subscribed to MovieMax, the navigator can direct
`that user to the MovieMax preview channel, can
`notiir the user of special sign-up offers, or allow
`him or her to sign up online (self provisioning).
`With a downloaded navigator, the cable operator
`has direct control over the look and feel of the
`EPG. They can organize the guide in such a way
`that the services with the highest profit margin
`(IPPV perhaps) are given prominence. They can
`put effort into human factors design to help ensure
`that the consumer's experience is productive and
`pleasurable.
`
`FACING REALITY
`What's wrong with this dream? A troubling
`aspect of this code download scenario is the
`implied notion that every retail device, regardless
`of manufacturer, make, or model, would behave in
`exactly same way. In the following sections we
`first explore this product differentiation problem'
`and then discuss funher difficulties, including:
`Problems with the overall philosophy of
`cable- operator-supplied downloaded code
`Technical challenges, such as reliability
`and the difficulty of porting the API
`Challenges related to the magnitude and
`complexity of the problem
`The paper goes on to suggest some resolutions
`to these problems, and describe example products
`we would like to be able to manufacture once the
`
`software download system design and
`specifications are complete. We then suggest a
`way forward in the near-term, bridging between
`technologies available today and that which we will
`develop and refine in the next several years.
`
`From the point of view of the consumer
`electronics manufacturer, the idea that every model
`of every manufacturer's product ultimately runs the
`same cable operator-supplied code causes real
`marketing problems.
`
`Competition in the marketplace
`Consider a high-end product &om manufacturer
`A compared with a high'end product from
`manufacturer B: when compared side-by-side on
`the sales floor, both products will appear to be
`identical once downloaded with the local cable
`operator's application suite.
`
`Low. middle. and hieh-end
`Commonly in consumer elgctronics marketing, a
`manufacturer offers low-end, middle, and high-end
`products. The middle of the road product offers
`iome features not found on the low-end model, and
`the high-end product offers bells and whistles not
`found on the level below.
`Perhaps the low-end product doesn't support
`software download at all. But let's say the middle
`and high-end products do support the OpenCable
`Middleware Solution. Once downloaded with the
`cable operator's application, when either of these
`boxes accesses a cable service, the user experience
`is the same (aside from factors like CRT display
`size).
`In this world" a manufacturer can no longer
`differentiate one product from another based on a
`software-related feature.
`
`Native ?pplications
`A native application is one written in or
`compiled to the machine code of the retail device's
`
`2000 NCTA Technical Papers - page243
`
`

`

`CPU. A cable operator may want to maintain
`control over native applications, for example by
`downloading a "Master Application" capable of
`authenticating them, launching them, and
`determining their privileges and resource usage. Is
`this practical, possible, or even reasonable? We
`think not.
`Given that each model of each manufacturer's
`product would typically have a different set of
`native code, it is entirely unclear how the cable
`operator's downloaded application could be
`afforded such control.
`Consider that a cable-ready device offered for
`retail sale must have some level of functionality
`even before an operator-supplied code download
`occurs. For example, it will likely provide acsess
`to analog and free services on cable, assuming that
`the user has a basic cable service. It would provide
`some form of user setup and/or diagnostic
`functions even without a basic cable service.
`This native application cannot and should not be
`under the control of the Middleware Solution or the
`cable operator's downloaded application.
`ln fact, the native application needs to take
`priority over anything that might be downloaded,
`for example to allow it flush memory and re-
`initialize the unit in case of trouble. &, h case the
`user moves it to a new city and/or a new cable
`system.
`It is not only impractical but also unwise to say
`that an application provided by the cable operator
`should control the native applications in a retail
`device.
`The native application on the right in Figure 1
`accesses OS functions in the device directly. As
`shown, a companion resident application is also
`present. The resident app is written in a platfonn
`independent way by the manufacturer, and takes
`advantage of the middleware layer implementation.
`As shown, a cable-operator supplied
`Application Suite is presentn including a "master
`application." We feel that this master application
`should be the "master" of the elements of the
`application suite (EPG, VOD, web browser, as
`
`shown), but it cannot and should not be involved
`with the control of the resident or native
`applications.
`
`Let's say an API is eventually agreed upon, and
`some number of compliant platforms are fielded.
`In a year or two, as history tells us, typical CPU
`speeds will be doubled, memory prices will be
`halved, and graphics capabilities will increase by a
`large factor. In two years it may be cost effective
`to include video hard disks in most devices.
`If the MSO or cable operator does not create a
`new application suite tailored to the 2nd generation
`plafornr, the power of any new available hardware
`cannot be fully exploited. The size and capabilities
`of the application are limited by the least common
`denominator platform.
`If the solution is to provide a new application
`suite to be run on the next-generation boxes, where
`does this progression stop? The process of
`defining and standardizing new platforms and API
`extensions is never-ending as the operator's
`configuration control and management problem
`becomes exponentially more difficult.
`How many new downloadable applications
`rrright any MSO develop over a five-year period?
`We think the answer is something like one or two
`at most, given the enonnous complexity of the task.
`A software release for a large cable plant must be
`rigorously and thoroughly lab-tested before large-
`scale deployment. Testing such an application
`would be an unprecedented challenge because of
`the large (and growing) number of target platforms
`upon which the application must be validated.
`
`Control over c// cable-delivered services
`A cable operator may want to use the
`downloaded application to control the look and feel
`of all cable-delivered services, including the
`DOCSN cable modem. Clearly, the operator
`gants or denies access via the cable modem to the
`Internet. Access to cable modem services is based
`on whether or not the consumer has paid for a
`subscription to the cable modem service.
`
`2000 NCTA Technical Papers - page 244
`
`

`

`Resident
`App
`
`Middleware
`o''
`
`,{
`
`Application Platform Client
`(Middleware lmPlementation )
`
`Native
`App
`
`CPU & Hardware Devices
`
`Figure l. Software Architecture of a Representative OpenCable Retail Box
`peripheral and program source for other devices on
`But if a cable modem service has been paid for,
`a home audio/video bus, but it wouldn't have a use
`,*,hat control over the "look and feel" of it can a
`for (let alone the resources to support) a cable-
`cable operator hope to impose? It will be the
`authors of HTML content on a websiteo for
`operator-suppl ied navi gator appl ication'
`example, that will determine the appearance (and
`Even if the PVR could accept an application, a
`look and feel) of presentations based on that
`PVR is a PVR and not a DTV. The application
`must account for the functional aspects of the type
`content.
`of host platform it runs on.
`Perhaps the cable modem in the set-top or DTV
`is connected by Ethemet to a PC' How could the
`Any cable-operator supplied application must
`cable operator have any control or impact of the
`take into account aspects of the platform upon
`which it is expected to run. An application
`on-screen look and feel on the PC screen?
`downloaded to a retail set-top box must be
`optimized for a set-top box type of product, just as
`an application for a DTV must be adapted to the
`DTV.
`
`A cable MSO may want to create a single
`application for deployment across the full range of
`OpenCable host devices available at retail. That
`suggests that the same application that runs in a
`retail DTV also runs in a D-VHS recorder, retail
`set-top box, or cable-connected Personal Video
`Recorder (PVR). Upon reflection, it will be clear
`that the one-application-for-all-devices goal is
`unreasonable.
`For example, the PVR may be a low-cost device
`that happens to have a cable tuner but no user
`interface of its own. It can act as a slave storage
`
`Control over a// resources
`A cable MSO may wish to use a downloaded
`application to control a// resources available on the
`host device. We see a difficulty here.
`Let's say a new model of consumer device
`offers wireless connectivity to other devices' Can
`the cable operator's downloaded application have
`access to the resources offered by the wireless
`port? Such access will not be practical until the
`
`2000 NCTA Technical Papers - page 245
`
`::
`
`ti
`
`i
`
`#
`
`

`

`Middleware Solution itself is extended to support
`wireless access. How can the application take
`advantage of wireless access anyway, given that the
`capabilities of this particular host device are
`unknown to it?
`Furthermore, as an unending succession of new
`types of resources are invented and popularized,
`will the Middleware Solution be continually
`extended to include each new one? This seems
`impractical as a road forward.
`
`TECIINICAL CHALLENGES
`
`100% reliability
`The reliability of the cable-ready device is very
`important. Clearly, we cannot allow tomorrow's
`digital television or set-top box to move anywhere
`near today's notion of a PC, where progrrlm crashes
`and the need to re-boot the machine are frequent
`and commonplace.
`On the other han4 100% reliable crash-proof
`code is impractical with today's technology,
`especially given the size and complexity of the
`code involve4 and the environment in which it is
`intended to run.
`Even with the Java programming language and
`its elimination of pointers, some tJpes of
`programming erors can cause available memory to
`diminish to zero over time. The program may not
`"crash" but it can become unusable, non-responsive
`to RCU keys, and require some form of re-booting
`or reset.
`Another form of crash can occur as two separate
`software processes, or o'threads," both firy to access
`the same data sffucture in memory' Unintended
`results can occur, or in some cases a "deadly
`embracen' can result where both processes are
`blocked from further operation.
`Also, of course, software testing isn't foolproof.
`By some reports for example, the first release of
`Windows 2000 included 63,000 known "issues."
`The count didn't include those bugs not yet
`discovered ofcourse.
`It is possible to write a very stable application
`that will function reliably for long periods of time,
`given a stable and well-understood environment in
`
`which it can execute. The challenge we face in the
`OpenCable approach is that the environment is not
`always well known. There will be many platforms
`and many implementations.
`
`Lack of standards for code download and
`authentication
`Compared to the issues above, this one is rather
`easy. Security functions in an OpenCable
`compatible device are handled within the POD
`module. Standards are needed to allow a Host
`device to make use of API calls to the POD module
`to determine if a particular piece of executable
`code has come from a reliable source, with no
`tampering or comrption. Some early proposals
`have been floated to some standards committees
`addressing this need.
`
`Portins a comolex API definition
`When a manufacturer wishes to support the
`OpenCable Middleware Solution in a product, it
`may be necessary to port it to the Operating System
`chosen for that product. If the OS is a common
`one, it is possible that an implementation of the
`Middleware Solution standard for that OS can be
`purchased. Even so, there will always be a
`significant amount of work involved-the device-
`level support aspects must be home-grown in
`almost all cases. These include the aspects of
`tuning, demodulation, MPEG-2 decoding, SI
`section filtering and parsing, graphics and display
`control, audio control, front panel and RCU
`interface, signal switching and routing, and
`communications protocol stacla.
`
`Cost and retum on inveslment to support
`standard API
`Once the Middleware Solution is standardized"
`manufacturers of cable-compatible devices will be
`asked to provide support for it. The cost to add
`support for this API will be nontrivial. Many
`megabytes of RAM and ROM will be required. A
`significant portion of the cost to develop such a
`product will be involved with testing the
`implementation.
`The manufacturer is likely to ask 'khere is the
`return on my investment to include support for this
`API? Will my customer recognize the value of it to
`the extent that it increases the cost of the product?"
`
`2000 NCTA Technical Papers - page246
`
`

`

`complex, the IBM BIOS is small and very well
`defined.
`In the world of satellite TV, different vendors
`can license the technology needed to build satellite
`IRDs compatible with a certain operator's signal'
`Typically, the number of manufacturers is quite
`r-utt 1tttt"" or so). Each manufacturer is free to
`use a proprietary hardware platforr4 APIs and
`native appiications. Nevertheless, the compliance
`testing conducted by a typical operator is quite
`complex and time consuming.
`The essential difference in the case of retail
`cable-compatible devices is that l) the API is very
`large and iomplex, and 2) there are likely to be a
`utf l"tg" number of equipment manufacturers'
`each with multiPle Products.
`
`SUMMARY OF ISSUES
`In summary, the following issues and
`difficulties with the Middleware Solution concept
`proposed for OpenCable have been raised here:
`o No provision for or acknowledgrnent for the
`n"ed fot product differentiation is made
`Authenticating and controlling execution of
`native appliiations is impractical and
`unnecessary
`There is a clear need for a well-understood
`evolutionary path, or of an approach to
`realizing extensibility in a practical way
`The concept of "one application for all retail
`devices" is imPractical
`"Crash-proof' code is practically impossible
`The cost of implementation and testing the
`API is an issue to the CE manufacturer
`Certification and compliance testing will be
`an unprecedented challenge
`
`a a
`
`GOALS
`The following sections outline proposals for an
`expanded Middleware Solution corcept that we
`tht'nk can work for consumer electronics
`
`After all, it is the cable operator that will reap the
`monetary benefits. For manufacturers to embrace
`the standard API concept, it appears that some form
`of business arrangement will need to be made with
`cable operators as an incentive.
`
`TIIE CEBTIFICATION CHALLPNGE
`
`Many compliance and interoperability questions
`are raised by the notion of a standard software API
`to be used by retail consumer devices. How will a
`manufacturer certiS' that a certain implementation
`of the Middleware Solution is fully compliant?
`Given the large number of manufacturers involved,
`and the need to individually test each different
`product from each manufacturer, the number of
`products needing testing in a given year is very
`large.
`While Cablelabs has undertaken to certify
`standalone DOCSN modem implementations, that
`organization does not appear to be capable of
`supporting, on its own, certification of all these
`new consumer devices.
`The Middleware Solution specification
`document is likely to be extremely large and
`complex. As an example, consider the candidate
`specifications promoted by ATSC by the DTV
`Application Software Environment (DASE) group
`""0 UV Sun Microsystems in the JavaW effort'
`T\e 922'page DASE API specification (version
`1.08.01) includes over 350 Java packages, classes,
`and interfaces.
`One might ask, "What's new here-haven't
`there been other similarly challenging compliance
`problems?" I think the answer i$ "no." Let's look
`for some examPles.
`In the realm of Microsoft-Intel PC platforms,
`certainly there are a large number of manufacturers
`and implementations, but the compliance problems
`are much simpler. Most importantly, all platforms
`use the same type of CPU, so all code is "native"'
`Compliance testing has been achieved and many
`vendors have created clean-room implementations
`of the Basic VO System (BIOS). If the BIOS is
`compliant, any Operating System or application
`riding on it will work' Unlike the OpenCable
`Middleware Solution, which will be very large and
`
`2000 NCTA Technical Papers' page 247
`
`

`

`resident app needs to be able to take conffol ofthe
`user interface.
`The manufacturer's native application needs to
`be able to "register" with the Middleware Solution
`so that it can be notified about certain events' For
`example, it may want to be notified whenevsr
`events of the following t]?es occur:
`Any tuning-related API is called
`The user targets a program scheduled for
`future viewing (for example to set a timer)
`A timer activates or exPires
`An Emergency Alert notification is received
`Access is made to web content related to the
`television Program being viewed
`The API must support such aqcess to these
`events, as well as any others deemed useful by the
`implementation.
`
`a a a
`
`a a
`
`Support {or hardware feat,urqs
`A Middleware Solution may be implemented on
`various devices, each with a different set of
`included hardware and interface features' These
`might include 3D graphics acceleration, special
`.oit"nt decoding formats (MPEG-I, DirecTV
`transport, etc.), support for specific peripheral
`devices on the IEEE:1394 serial bus, camera and
`video input ports, game controller ports, USB'
`-
`peripherals, DVD player/recorders'
`storage
`persolnat vidio recording capability, format
`conversion (camcorder to MPEG, etc'), wireless
`communications ports and protocols, or countless
`others.
`If any of these hardware-related features are
`present in the cable-compatible dwice' the
`manufacturer-supplied resident and native
`applications m*t b" afforded access to them'
`Fixthermore, to the extent possible via API books
`and extensions, the native code should be able to
`integrate them with the cable operator-supplied
`application suite.
`For this philosophy to worlg some fundamental
`aspects of the Middleware Solution API may need
`to change.
`
`manufacturefs as well as cable operators and
`MSOs. The most fundamental proposed change is
`that the Middleware Solution must support resident
`and manufacturer-supplied applications alongside
`the cable- operator-supplied downloaded code'
`We first argue why this change is necessary, and
`then describe some of the new system requirements
`that result.
`
`URGE
`The competitive urge must be preserved' If a
`Middleware Solution were designed such that
`product differentiation was not supported the only
`for a manufacturer would be to make the
`"trutt.ngt
`most coit-effective implementation' Enhancing the
`product line with more and better features could
`not *"*. lnnovation would be stifled'
`Clearly, this scenario is unacceptable' Product
`differentiation ultimately benefits both the
`consumer electronics industry and the cable MSO'
`If we agree that product differentiation must be
`possible, then the following conclusions rssult:
`r The Middleware Solution must support
`unrestricted execution ofnative and resident
`applications, under control of the consumer
`(not tne cable operator). This was discussed
`above.
`r The Middleware Solution must support
`native or manufacturer-specific extensions
`and "hooks."
`r The Middleware Solution must allow any
`specific implementation to fully take
`advantage of (on its own) hardware and
`interface features that migbt be present'
`. Communications resourses such as the cable
`modem must be freely available to the native
`and resident applications (grven the proper
`basic authorization for cable modem service,
`of course).
`
`To support certain desirable product
`-features,
`the resident or native application needs to be aware
`of certain user actions. In some cases in fact, the
`
`2000 NCTA Technical Papers - page248
`
`

`

`3.
`
`4'
`
`5.
`
`1.
`
`Support for a sophisticated file system for
`peisonat video recording on a built-in hard
`disk
`Support capture of video clips via a CCD
`pott ot images from a digital
`"urrl"ru
`camera for attachment to e-mail
`Support an enhanced navigator functi-on,
`web-hosted databases with data
`"ooibioing
`derived from expressed user preferences
`and observed viewing habits
`Support a marketing product tie-in service,
`allowing the user easy access to prodlcts
`and t"*i""t associated with broadcast
`television Programs
`Support a feature where the device acts as
`u tio*. audio/video master control center'
`capable of routing signals between a/v
`equipment throughout the home
`6. Support a "home gateway" function
`inciuOing a private personal website'
`through *t ict the homeowner may login
`from anywhere in the world to access guide
`data, check on and set recording timers'
`check home security and access other
`equipment controlled by the device'
`The standard Middleware Solution may or many
`not include APIs that would support this set of
`features (it's not likely). Even if it did, while a
`cable'opeiator supplied application suite could
`possibly use the standard APIs to include these
`Lututtt, it is extremely improbable'
`Even if the operator-supplied application suite
`did do a few of these features, the user should be
`able to choose which he or she wishes to use'
`
`EXAMPLE PRODUCTS
`
`The following sections explore some possible
`cable-compatible products to show how the
`concepts we have Presented aPPlY.
`
`This product combines a state-of-the'art video
`game machine with a cable-compatible digital
`ielevision. A DOCSIS cable modem is included so
`that interactive games may be played via the
`lnternet.
`way of review, here is a brief list of the
`By
`issues:
`If the video game platfonn uses DOCSIS (a
`cable service), and the Middleware Solution
`must rule the look-and-feel, how can that
`work on top of the video game? Clearly each
`individual game played on the game console
`has its own look and feel.
`How could the Middleware Solution
`authenticate each game before it is played?
`Clearly that's not possible nor is it needed'
`To save cost, eliminate redundancy, and
`provide proper sharing of resourceso the
`video game application may want to take
`advantage of API calls within the
`Middleware Solution' Such sharing of the
`API appears not to be allowed in the current
`middleware concept.
`The cable operator's downloaded application
`is supposed to be offered the ability to
`interfiCe to any native extensions (in this
`case, the video game hardware and software
`supporf library). This can't work because
`thiie extensions are very likely to be
`proprietary. Even if they were open' the "one
`appiicatiott" likely couldn't take advantage of
`.iJout"tt available only in a small fraction of
`implementations.
`
`Consider a high-end cable-compatible device to
`be offered for retail sale. The manufacturer of this
`device is aggressively leading-edge and wishes to
`offer the following product features:
`
`ln an environment that includes a cable-operator
`supplied application suite alongside the
`**uf"atot"iJ native code, some new challenges
`arise.
`
`Memory management issues
`The cable- operator-supplied application will
`require or request certain memory resources (RAM'
`hard disk file space), as will the
`Flash-ROM,
`"urn
`
`&
`
`2000 NCTA Technical Papers - page249
`
`

`

`these to have actively executing threads, contention
`for resources can result.
`For example, both applications may wish to
`make use of ine nrning API. If one has conffol of
`tuning, the other will need to deal gracefully with
`the u-navailability of that resource' This simple
`approach may reiult in sorne undesirable behavior'
`where sven a high'importance request can go
`ungranted. Such problems suggest that a priority
`..htmt should be adopted for resowce
`
`management.
`Clearly, a new level of complexity is introduced'
`Such priority mechanisms have been discussed in
`,o*"'gto.rps, but the problem has so far not been
`brought to a clean solution.
`
`EVOLUTION
`Given the scope and magnitude of the
`unresolved issues, we feel that we are perhaps two
`to three years away from a workable solution to
`general-p-urpore cod" download' So, in light of
`itrese Oiinculties we present here a proposal for a
`practical way forward that can benefit both the
`cable operator and retail device manufacturer'
`We start with the defrnition of a cable'
`compatible device that can be built today, using
`cunently published SCTE and OpenCable
`standaris. The stepwise evolution therefore starts
`exactly where we are todaY.
`
`Level0: the "Watch TV" box
`The features of the level 0 box
`following:
`Performs the basic'lratch TV" function'
`Conforms to the OCI-N network interface,
`tunes/demodulates 64' and 256-QAM' etc'
`Supports all video formats defined in EIA-
`818 and OPenCable, either bY down-
`converting to NTSC, or passing compressed
`HD video vial394 to DTV.
`Navigation based on SVEPG tables as
`standardized bY SCTE DVS.
`
`a a
`
`resident or native application' The resident and
`downloaded applications may both request, through
`API or OS calls, "all the remaining memory"'
`Once a system of cooperative sharing of
`memory resources is worked out, both these
`.o*p"iiog entities can peacefully co-exist'
`Another problem relates to management of the
`per$istent storage. A Flash memory file system is
`example of a persistent storage system' The file
`'an
`system is often used by applications to store
`pieferences, passwords, "cookie" type data'
`viewing history, forms data, or any other data that
`has some kind of lasting value'
`The problem arises as the file system inevitably
`overflows, and no more space is available to create
`new files or to expand the size of existing ones'
`Some kind of file space reclamation process must
`be run. That process must decide which files are
`good candidates for permanent deletion'
`With personal computers, we don't allow such a
`process io make decisions about what files to
`ielete. We do it manually. Writing a file space
`reclamation routine will be a challenge, because
`unexpected results can easily occur when files
`by a certain application turn up missing'
`"*p""t"d
`Securify Policy issues
`ln a typical Middleware Solution, a security
`policy is an inherent part of the. API' ..Through
`an
`enforced security policy, certain applications can
`be granted or denied access to specific API calls'
`A lava applet, for example, is not allowed to
`perform file VO'
`As discussed above, we do not feel it is
`workable to allow the cable operatoros master
`application to dictate and establish all security
`poii"i"t in effect within a cable-compatible device'
`^So
`the question is open: who will allow whom to
`do what? Agreements on management of security
`policies will need to be worked out and
`documented.
`
`Reso.lirrce sharins issues
`In the scenario we are discussing now, an
`application suite provided by the cable operator is
`pt"rtttt alongside a manufac