THE COMPLETE TECHNICAL SESSION PROCEEDINGS
`
`FROM:
`
`
`NCTA*THENATIONALSHOW
`CHICAGO, IL * JUNE 8 - 11, 2003
`
`NCTA’s 528° ANNUAL CONVENTION AND INTERNATIONAL
`
`EXPOSITION
`
`Published by:
`
`Compiled by:
`
`Mark Bell, Director, Administrative and Technical Services,Industry Affairs/Administration
`AndyScott, Director, Engineering, Science & Technology
`
`Audio recordings for eachsession are available for purchase—check yourfinal
`program guide at the National Show, June 8-11—or phone NCTA's Industry Affairs
`departmentat (202)775-3669 for details. For availability and price information on
`previous volumesin the Technical Paperseries, call NCTA's Science & Technology
`departmentat (202)775-3637 or e-mail technicalpapers@ncta.com.
`
`ISBN # 0-940272-34-2
`
`DISH Ex. 1064, p. 1
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`CONTENTS
`2003 NCTA Technical Papers
`
`Consumption Junction: What’s Your
`
`Moderator: Jim Farmer, Wave 7 Optics, Inc.
`
`Gerry White, Motorola Broadband Communications
`
`Tiered Data Services to Enhance Customer Value
`and Revenue: Why Are DOCSIS 1.1 and Advanced
`Queuing and Scheduling Required?....c.c.csssssssssseseseeseoere I
`
`Amol Bhagwat, Cable Television Laboratories, Inc.
`Quality ofService Over Home Network Using
`CableHome™ 1.1 ...scscsssssssssseecsssssesesssssesesersnscesnunesssncces 15
`
`Michael Chen, Concurrent Computer Corporation
`Anything, Anytime, Anywhere: Open Advanced
`Bandwidth Management of On-Demand
`SEPVECES <vesusicccniossstnieszscestieresorvsvossvanenaninbecessesadsccsedsasion 29
`
`Yakov Kamen,Entelel Corporation
`Mathematical ModelofInteractive Programming
`GUide.....sesssesereresesessscsssesensseeceseessensstecssnsssessssatsceneneasess 40
`
`Louis P. Slothouber and Aaron Ye, BIAP Systems,Inc.
`Artificial Intelligence in Cable TVApplications ............ 49
`
`Flexible Network Design: Realizing Path
`
`Moderator: Nick Hamilton-Piercy, Rogers Cable, Inc.
`
`Donald Sorenson, Scientific-Atlanta, Inc.
`Feeder Fiber Infrastructurefor the Small to Medium
`Business Data Services........ccssecssssssscsessssssessesssecsensssenee 57
`
`Gil Katz, HarmonicInc.
`Switched Broadcast Cable Architecture using
`Switched Narrowcast Network to Carry Broadcast
`SOrVICES....secsevssssosssecsensosssssescorsseesssccsssnssnsnsassseesssesessens 70
`
`Ran Oz and S. V. Vasudevan, BigBand Networks,Inc.
`Network Designfor a Multiplicity ofServices cs... 75
`
`Oleh J. Sniezko, Aurora Networks,Inc.
`Fast Ethernetin the Last Mile ......c..c.cceccsssesscssesseosesessee 83
`
`Andy Woodfin and Boh Ruffin, Coming Incorporated,
`Jim Painter, Comcast Corporation
`Advances in Optical Fiber Technologyfor Analog
`Transport-Technical Advantages and Recent
`Deployment Experience .....s.ssesessersssesesessssvssesssnssenereees 93
`
`Packet Up...I’ll Take It: Managing
`Tomorrow’s IP Traffic
`
`Moderator: Dan Pike, GCI Cable and Entertainment
`
`Burcak Beser, Juniper Networks
`Building Competitive Systems: A PacketCable
`POrSPeCtiVe ......sssesversrecssneessessereneenssesssncsesnsassssasacsesees 101
`
`Daniel Howard, Laura Hall, Keith Brawner,
`and Hans Hsu, Broadcom Corporation
`Nick Hamilton-Piercy, Reynold Ramroop,
`and Sheng Liu, Rogers Cablesystems
`Methods to Increase Bandwidth Utilization
`in DOCSIS 2.0 Systems vercscsesssereserssessssecsscsssscsecteseceees 110
`
`Benoit Legault, ADC
`Routerless Aggregation: Converging Data and
`TDM Netw0Fk ......ssscssscsssssesssesseersasssssseassesssesssecsceees 118
`
`John R. Pickens, Ph.D., and Greg Hutterer, Allot
`Communications, Inc.
`Managing Peer-to-Peer Traffic - Beyond
`DOCSIS 1. .esssssssesssssssssssnssssesesecsssessenssnsessesunsesescnees 124
`
`Jonathan Schmidt, Perffech Bulletin Services
`Theft ofService in High Speed Data Services:
`A Way to Deal with This Difficult Problem.cu..sso00. 133
`
`Whole-Home Networking: A House No
`LongerDivided
`
`Moderator: John Lappington, Broadcom
`
`DaveClark, Scientific Atlanta, Inc.
`Multi-Room DVR: A Multi-Faceted Solution
`for Cable Operators...csecssesssersresseeessserssvesessesnssnenssesees 142
`
`DISH Ex. 1064, p. 2
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`John Amaral and Paul Pilotte, Artel Video Systems
`Packet Network Topologiesfor Next Generation
`Video On Demand and Switched Broadcast
`Service Delivery..esscsscseccsssssssessessesssserssesevsessensesecssees 243
`
`Ardie Bahraini, Motorola Broadband
`Communications Sector
`Carriage ofMPEG-4 Over MPEG-2 Based
`SYSTEMS..14..sessnessorsoersnssonssvescsersssussasteeseseeseosoesoecsssosses 256
`
`Doug Makofka, Motorola, Inc. Broadband
`Communications Sector
`Controlling an Infinite Number OfChannel.......scs000 266
`
`Robert G. Scheffler, Broadbus Technologies, Inc.
`Ingest & Metadata Partitioning: Requirements
`for Television On Demand™.....ccccsssssessesrsesssesssessseseces 274
`
`Cable and ConsumerElectronics...
`A Vegas Wedding?
`
`Moderator: William Check, Ph.D., NCTA
`
`Brian Markwalter and David Broberg, Consumer
`Electronics Association, Cable Television
`Laboratories
`Cable & CE Industry Cooperation on
`Unidirectional Digital Cable Receiver..cc..cceccecsecsssss. 284
`
`David St. John-Larkin and Jud Cary, Cable Television
`Laboratories,Inc.
`Legal Issues in a Trusted DOMAIN vessserseccsscessesssssesseses 290
`
`Mark Eyer, Sony Electronics
`New Developments in IEEE-1394 Standardsfor
`the Cable Set-Top Box ....csecesrscvsssessssessesssssecessseseseosees 305
`
`Nandhu Nandhakumar, Jian Shen, and Gomer Thomas,
`TriveniDigital, Inc
`Implementing and Verifying Off-Air DTV Carriage
`Contracts in Cable HeadendS.....cc.ssesseesssccssssssesssssssscs 316
`
`Sylvain Riviere, BigBand Networks,Inc.
`Seamless, Scalable HDTV Roll-Outs Over Today’s
`Headend ........sesssecvsressssrsansrvssssesssensssessesrssscasessssesceee 326
`
`William Garrison and Thomas du Breuil, Motorola, Inc.,
`Broadband Communications Sector
`Delivering Everything Everywhere in the Home:
`Whole Home Networking......e.osscsessssvessessesssessesecesees 145
`
`Doug Jones, YAS Broadband Ventures
`The Three Dimensions ofHome Networking.......s.00000. 151
`
`Carlton J. Sparrell, Ucentric Systems
`Flexible Whole-Home Networking Strategies
`in @ Multi-TV Environment....c.ccsccssssssvesssssssosersesessessns 160
`
`Joseph W. Weber and David Broberg, CableLabs
`Second Generation Point ofDeployment (POD)
`Interfacefor Multi-Tuner Cable Receiving
`DOVICER.ronneseeseoessesabchselieetiiitentssvesscesatipssissects)nctel 169
`
`Don’t Be Long, The Meter’s Running: New
`Tools for Tiering
`
`Moderator: Doug Semon, Time Wamer Cable
`
`Alexandre Gerber, Joseph Houle, Han Nguyen, Matthew
`Roughan, and Subhabrata Sen, AT&T Labs - Research
`P2P,the Gorilla in the Cable wscccceccecessussserscssecsessesosee 174
`
`Robert L. Howald, Ph.D., Motorola Broadband
`Business and Pleasure: Mixed Traffic Issues
`Drive Network Evolution....cc.cs.cscsssssscessesessssseseseseseess. 186
`
`Michael Ben-Nun, P-Cube Inc.
`Taming the Peer to Peer Monster Using Service
`CONTI....esessesnessenseneesssnesnesussnsavsnesesassassesestvensenseseece 204
`
`Kenneth Gould, Time Warner Cable
`DOCSIS 1.1 — Where Gaming and Quality ofService
`(QOS) Intersect...ccsserverscseenssssssessssessessssssesssssensseeseeees 213
`
`F. Eugene Rohling, DVA Group,Inc.
`A Method ofAnalyzing MPEGData in Encapsulated
`SETEAIS1-v-cecveressasasoussorenvensenecigacsosensesseseecenseccoreesonseses 219
`
`Doug Jones, YAS Broadband Ventures
`DOCSIS™ Toolsfor Tiered Data Service.receccec.os....... 226
`
`Subscribers On-Demand:Delivering What
`They Want, When They WantIt
`
`Moderator: Dom Stasi, TVN Entertainment
`
`Junseok Hwangand Srinivasan Nallasivan, Syracuse
`
`Modeling the Scaling Properties of Video On
`DemandAccess Networks: Simulated Traffic and
`Workload Analysis ...sscsssecsssssssssssessssssssssssssseseszessssssees 232
`
`DISH Ex. 1064, p. 3
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`INGEST & METADATAPARTITIONING: REQUIREMENTS FOR
`TELEVISION ON DEMAND
`
`Robert G. Scheffler, Chief Architect
`Broadbus Technologies,Inc.
`
`ABSTRACT
`
`asset distribution, content propagation,
`network loading, metadata andrules issues
`need to be addressed to make Television on
`Demand a commercialreality.
`
`This paper will address the issues and
`requirements associated with server ingest
`of broadcast content and content
`propagation. It will also discuss the
`architectural implicationsfor the VOD
`server and propose a new class ofserver to
`support TOD requirements. The paper will
`also discuss how TOD content is managed
`through the creation and distribution of
`enhanced metadataformats in an
`environment that is controlled by studios,
`distributors, and cable operators.
`
`On demand videoservices, such as
`today’s Video on Demand (VOD),
`Subscription Video on Demand (SVOD), and
`thefast-approaching Television on
`(TOD®)are enhancing the
`consumertelevision experience and creating
`new, exciting revenue opportunities and
`increased cashflowfor cable operators and
`content owners alike. However, the
`technical requirements to support these
`services are becoming more demanding and
`complex. In VOD, cable operators are
`seeing solid buy-in rates, repeat purchase
`patterns, and concurrency rates of3%-10%
`with limited marketing and promotional
`support. With recenttrials of SVOD and an
`increased numberofpopulartitles,
`concurrency rates have ‘smoothed’ the peak
`usage rates throughout the week to numbers
`that often approach 10%-20%. However,
`with Television on Demand (TOD)services,
`consumers will have considerably more
`programming choices including movies,
`
`VOD/TODCONTENTINGEST
`subscription-based content, and the most
`popular broadcastcontent. It is anticipated
`that concurrency rates of TOD may steadily
`climb to levels that approach 30%-65% --
`rates that mirror the total concurrent U.S.
`television viewing audience as measured by
`rating services such as Nielson.
`
`New video server architectures and
`rules-based content control and propagation
`systems becomeintegral contributors to the
`success offuture on-demand services.
`
`The issue of the ingest of broadcast
`television contentis one that will become
`more and more important for advanced
`video services such as Television on
`Demand to becomea reality. As more
`content is made available and concurrency
`rates increase, architectural decisions will
`have to be made to support these increased
`demands on the network. A new architecture
`comprised of higher density VOD/TOD
`servers with the capability to ingest
`
`Increased service usage, additional
`content, and new business models are
`challenging MSOs to conduct unprecedented
`network architecture preparation and
`planning. In addition, decisions related to
`
`DISH Ex. 1064, p. 4
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`broadcasttelevision will be required to
`support ever increasing contentlibraries and
`stream counts. Howeverit is important to
`look at the evolution of VODarchitectures
`to understand how those requirements will
`changein the future.
`
`processing capacity to focus onthe ingest
`functions. This was very labor intensive
`with a single operator feeding tapes and
`entering rules to instruct the STB guide
`software aboutthe pricing and availability of
`newtitles (see Figure 2-1). Keeping up with
`content ingest was quite manageable for the
`VODinthePast
`operator and the conventional VODserver.
`
`In the early days of VOD, movies were
`distributed on tapes, These tapes were
`shipped to eachsite that required a specific
`movietitle. Using an encoding rate of 3.375
`Mbpsand an average movie length of 100
`minutes, the total size of each movie was
`roughly 2.4 GBytes. A typical installation
`might contain a library of under 100 movies
`and was capable of streamingto less than
`1,000 subscribers simultaneously.
`
`
`
`Person
`
`Figure 2-1 Content Ingestfor VOD in the
`
`In early VOD deployments, metadata or
`other business rules weren’t typically
`supplied with the content. The operators
`themselves were responsible for deciding
`what rules applied to particular content and
`for entering the appropriate rules into the
`VODserver or control system. This
`relatively simple model meant that most of
`the attention was focused onthebilling
`interfaces, set top box (STB)client, and
`head-end control, With low stream counts,
`movie titles could be loaded during off-peak
`hours when the VODserver had more
`
`VOD Today
`
`As an industry, VOD has matured
`beyond the simplistic example described
`above. VODinstallations now enable 1,000
`to 3,000 customers to access a library of 150
`to 300 movies. As a result, shipping tapes to
`VODenabied head-ends has proved to be a
`logistical challenge and has evolved to a
`newer model called pitch-and-catch, where
`contentis distributed by private broadcast to
`remote stations and syndication partners via
`satellite (see Figure 2-2). With increased
`library sizes, increased stream counts and
`more diverse suppliers sending data, the
`distribution and propagation of content has
`shownitself to be quite a challenge. Content
`can still arrive on tapes and is caught by
`catchers along with trailers, posters, and
`Tules that are required to putit all together.
`
`Person
`
`Tape drive
`
`Content
`
`Figure 2-2 Content Ingestfor VOD today
`
`Content aggregation companies have
`risen to the challenge by offering services to
`edit, adjust, and compile these diverse
`formats and metadata into a nice bundled
`
`DISH Ex. 1064, p. 5
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`packageto be pitched and caught. However,
`a fundamental problem is that while quite
`adept at low-volume streaming,
`conventional VODservers usually lack in
`their ability to simultaneously ingest large
`quantities of content. The situation
`multiplies itself as we add streams, services,
`storage, and begin to distribute more
`hardware throughout the network.
`
`large amountsof content propagation. To
`now handletheingest ofa significant
`amountof content, a conventional VOD
`server will typically lose some, or much of
`its streaming performance.
`
`Today’s VODserver systems adequately
`accommodate the demands of low-
`concurrency VOD/SVODdeployments.
`However, adding the task of ingesting
`
`CombiningSVODwithVOD
`numerouschannels of broadcast content to
`conventional VODservers creates a massive
`Subscription VOD (SVOD)increases the
`hardware and software infrastructure that
`existing VODcontentlibrary by adding 50-
`takes upalot of space, consumesa lot of
`100 movies and other content and making
`them available to an increased number of
`subscribers. Even with a limited amount of
`contentoffered, trials of SVOD to date have
`resulted in increased concurrencyrates that
`maybe as high as 10%-20% or 3,000 to
`5,000 streams in a typical system.
`
`power, and is inherently lessreliable.
`
`Figure 2-3 Content Ingestfor VOD in the
`future
`
`Television on Demand using Conventional
`VODServers
`
`Nowlet’s look at an example where we
`expand the VOD/SVODservice offerings to
`include Television on Demand (TOD). TOD
`enables cable operators to provide on
`demand delivery of live or pre-recorded
`broadcast television services as well as the
`movie and subscription-based content that
`VOD/SVODoffers. TODis especially
`attractive to television content owners
`because it allows the viewing and sale of
`older programmingthat is out of
`syndication. TOD enables the consumerto
`have PVR functionality during broadcast
`
`These concurrencyrates place
`tremendous demands on the streaming
`capacity of the network. Also as stream
`counts increase, so does the problem of
`content ingest. To increase the stream count,
`additional streaming servers are required.
`These additional servers need access to the
`library of ingested content. If a given piece
`of content is to be made available to every
`customer on the network, the content needs
`to be either locally stored or remotely
`accessible. One way to makethe content
`accessible is to add an ingest server or
`propagation server at the point where the
`content is caught or loaded from tape. This
`ingest server could then locally store the
`content, making it available to the rest of the
`servers. Alternatively the ingest server could
`be used to propagate ordistribute the
`content to the streaming servers, whether
`local or remote (see Figure 2-3).
`Remembering that the streaming servers are
`primarily intended for streaming, there is a
`fixed amount of bandwidth available for
`
`DISH Ex. 1064, p. 6
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`offerings. When VOD, SVOD,and TOD are
`combined a typical system may require
`20,000 to 40,000 simultaneousstreams. For
`example, using conventional VODservers
`capable of 500 streams each would require
`80 servers to satisfy the stream requirement.
`However, as more conventional VOD
`With Television on Demand,ingestion,
`servers are added, the problem of
`propagation, and streaming of content needs
`propagating the contentto all the servers
`to occur such that the customerstill feels
`increases exponentially and creates the need
`like they are watching broadcasttelevision.
`for more ingest servers to propagate the
`In addition to the plethora of content,
`content so that eventually there is a
`trailers, posters, and rules that VOD/SVOD
`hierarchy ofingest servers to streaming
`requires, there is nowareal-time
`servers. A conventional VODserver is
`requirementfor low latency content
`designed for streaming to customers, notfor
`ingestion. Current VOD/SVODsystems,
`moving, propagating and ingesting
`complete with catchers, tape drives, and
`television content. Therefore today’s VOD
`content ingest propagation now have to
`severs are not the optimum solution for this
`support the ingestion of broadcast television
`compelling, new application.
`feeds (see Figure 2-4). The path of the
`broadcast feed to the broadcast ingest server
`to the ingest and propagation server to the
`VODserver and then to the customers is an
`operation that will take many seconds and
`must occur at the same time as the
`propagation of VOD content to the VOD
`
`Deploying TOD with TOD servers
`
`The critical issues that must be addressed
`to adequately support TODare content
`ingest and stream count. A new class of
`TODserveris required that can ingest
`dozens of channels of broadcasttelevision
`while simultaneously redistributing
`thousands of streams with zero-latency. The
`associated delays can be removed by
`running the broadcast feeds for ingest
`directly into a TOD server where they can
`be directly streamed to customers without
`requiring an external hierarchy of
`propagation servers. This solves the content
`ingest and propagation problem presented
`by TOD. However, a hierarchical approach
`to storage is also required foroff-line
`VOD/SVOD/TODcontent access. Whatis
`needed is a distributed storage strategy with
`shared local storage as well as shared remote
`storage that decouples the streaming
`functions from the storage functions. By
`decoupling these functions, stream-count
`and storage-size can be scaled independently
`while storage can be placed in the network
`
`television viewing without requiring a hard-
`drive in the STB. At a minimum a TOD
`system should be capable ofstoring 1,000
`movies for VOD/SVODcustomers, plus
`10,000 hours of captured broadcast
`
`
`
`Figure 2-4 Content Ingestfor TOD using
`
`Consumerconcurrency rates for TOD
`will require a muchhigher stream count than
`the current growth projections for VOD
`
`DISH Ex. 1064, p. 7
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`specific applications with unique
`requirements.
`
`Summary of Content, Streams and Ingest
`
`As needs grow and new business models
`are introduced,the capacity and scaling of
`VODstreaming servers are being tested.
`Contentlibraries are increasing and greater
`concurrencyis leading to higher and higher
`stream counts (see Figure 2-6). With the
`introduction of TOD,the addedability to
`ingest broadcast television with low-latency
`is transitioning from an interesting feature
`into an absolute requirement.
`
`Conventional VODservers are being
`taxed to the limit with only a modest library
`change rate per month. As content libraries
`grow,to preventlibraries from becoming
`‘stale’ with old content, an increased
`demand is being placed onoff-line ingest.
`Even now, conventional VODservers are
`reaching their limits in being able to keep up
`with SVOD and VODapplications.
`Regardless of how muchstreaming
`requirements increase as TOD begins to
`proliferate, the cable operator will be forced
`to add additional servers just to handle
`ingest tasks. Even then, the resulting system
`will not adequately address the problem of
`broadcast ingest to streaming latency. The
`clearly superior solution is to use a new
`class of specialized TOD server capable of
`ingesting and directly streaming with no
`perceivable delay.
`
`where it can be used in the mostcost-
`effective way. A master head-end containing
`a pooled storage library would allow a group
`of servers to access lesser-used programs
`without requiring local copies. By using this
`distributed storage architecture, each type of
`content can actually be moved and
`positioned in the network forthe perfect
`balance between hardware and transport
`costs. As the needs of the network change,
`the placement of system components can
`
`changeas well.
`
`Figure 2-5 Content Ingest for TOD using
`TODservers
`
`A flexible architecture that can handle
`low-latency live-ingest as well as pitcher-
`catcher and tape based distribution models
`would be ideal for cost-effectively
`supporting TODapplications. The capability
`to decouple streaming from storage, while
`being able to distribute the storage anywhere
`in the network, would also significantly
`improve the economics of TOD. With
`streaming positioned in one place and
`storage distributed throughout the network
`the new architecture will scale to support
`even the most demanding TODapplications
`(see Figure 2-5). The future of VOD,
`SVOD,and TOD are dependent on a new
`architecture where scale can be controlled
`and each environment can be tailored for
`
`DISH Ex. 1064, p. 8
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`
`
`Application|Movie|Library
`Concurrency|Stream
`Real-Time
`Libra
`Change
`TV Inges
`Rate
`Count
`|VOD__|150-300|15/month|Ostreams|5%-10%_|1,000-3,000_|
`
`TOD/SVOD fea 100/month
`30%-65%
`20,000-40,000
`
`Figure 2-6 System Capacities for VOD, SVOD, and TOD
`
`was over, the movie would be deleted from
`the server. A set of rules, or metadata,
`
`Rulesareneeded
`capturing the pre-negotiated License
`WindowStart and End Times would be read
`and enforced by the VODserver.
`
`CONTROL
`
`The business of broadcast television
`today is very complex. The participants are
`numerous-- content owners, content
`aggregators, content distributors, broadcast
`and cable networks, MSOs -- and the
`relationships between the players are
`dynamic. Whatkeeps content flowing from
`creators to consumers is the execution and
`enforcementofdetailed contracts. These
`contracts determine the rules of “how”,
`“when”, and “by whom”content may be
`viewed. Whetherit’s a re-run episode of
`“Friends”that airs in syndication on TBS or
`a live broadcast of the New York Knicks on
`ESPN2,there are specific contract-based
`rules that govern the mannerin which
`content is handled. Therefore, it should be
`no surprise that a system of contract-based
`rules will continue to govern (and perhaps
`with greater emphasis)in a businessthat
`combinesbroadcasttelevision content with
`on-demand content.
`
`When VODwas initially deployed, the
`rules were relatively simple. MSOs would
`license a windowof time when a movie
`would be madeavailable to its subscribers.
`During the licensing window,the movie
`would be placed on the VOD Serverand be
`available to subscribers. After the window
`
`As the industry moves towards SVOD
`and ultimately TOD, the same set of
`complex rules andattributes must be applied
`to each piece of content. Examples of
`additional rules for handling television
`content couldinclude:
`e Specific days of week when content
`is available
`One or more timeslots during the day
`Time range that the program is
`available on a particular day
`© Specific commercials that must be
`carried with the program
`e Trick-mode rules and attributes
`(specific speeds, enabled/disabled
`functions)
`e Specific customer groups by
`demographic or geographic regions
`
`Rules should be entered and applied as
`early in the process as possible. There are
`rules from manylevels. Examplesinclude:
`e Content owneror studio
`Studio distribution arm
`Content aggregator
`Television network
`Localtelevision station
`
`DISH Ex. 1064, p. 9
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`e Cable MSO
`e Cable local unit
`Some ofthe rules apply to VOD, someto
`SVOD,and some only to TOD. Thekeyis
`that there are manyrules that can come from
`any numberof places. While it can seem
`daunting,it is quite easy to create and
`managetheserules.
`
`title, rating, description, time, actors,
`directors and crew,category,trailerfile
`names,posterfile names, etc. This type of
`metadata does not change, no matter who,
`what, when, or where it is distributed. This
`metadata could clearly be embedded in the
`actual contentfile and would stay with the
`file no matter where it goes.
`
`Partitioning Metad
`
`2. Rules-
`
`The Video-on-Demand Content
`Specification as published by CableLabs has
`become the de-facto standard of how
`metadata is created and how it can
`incorporate many ofthe rules necessary to
`describe how on-demand contentis to be
`handled. Initially written to support VOD
`(movies), ithas been expanded to support
`SVOD.Moving forward, it is likely that the
`specification will need to be expanded to
`support all forms of on-demand content,
`including broadcasttelevision.
`
`Some metadatarules pertain to the
`specific contentitself, while others apply to
`how that contentis distributed and sold. One
`piece of content from a studio can be sent to
`many cable systems across the country.If
`the studio had to regenerate the content
`metadata each time,it would become a
`painful process that nobody would want to
`use. However,if the content specific
`metadata were attached or imbedded in the
`contentitself, and the distribution specific
`metadata was separate, then the same
`content with metadata attached could be sent
`to manylocations, with a different version
`of the distribution metadata. Thus, the
`content metadata and the rules-specific
`metadata has beenpartitioned.
`
`Meta
`
`Content metadata includes program
`specific things such as a uniqueidentifier,
`
`The rules-specific metadata starts at the
`content creation studio. The studio decides if
`there are any specific restrictions on the
`distribution and sale of this content and
`passesthose rules along to the content
`distributors. For example, there may be a
`requirementto restrict a specific category of
`commercial - A “Friends” episode may
`require Coke commercials, but not Pepsi.
`From there, the studio distribution arm may
`require more specific rules. “Friends” may
`be allowed from Mondaythrough Friday
`anytime, but not Thursday from 8-9 pm, to
`preventintruding on first-run episodes.
`Further downstream, the television network
`may decide to allow viewing anytime on
`Tuesday and Wednesday because those are
`non-peak days. The local television station
`may wantto restrict viewing from 10-1 1pm
`during the local news hour.
`
`Content Owner
`
`Figure 3-1 Rules-specific Metadata Flow
`
`DISH Ex. 1064, p. 10
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`it was sold. An improved solution would be
`to ship the exact same content to each
`downstream customer, but each would be
`supplied with unique rules-specific metadata
`which can be changed or updated at any
`time without requiring the entire piece of
`content to be resent.
`
`CreatingMetadata
`
`At each step along the way,the rules can
`become more restricted, but cannotbe less
`restricted. In this manner, the content rules
`- become more and more defined as they
`propagate downstream to the network
`operator and eventually the consumer(see
`Figure 3-1), Each system along the path is
`responsible for obeying the rules imposed
`upstream, and can expect each system
`
`downstream to obeythe rules it passes on.
`Whenthey reach the cable system, the TOD
`menuor EPG is built using these rules for
`the content received. By using this approach,
`the menus for the STB can be automatically
`and dynamically constructed.
`
`
`
`Figure 3-2 Metadata Flow to Multiple
`Downstream Paths
`
`At eachstep in the process, there can be
`multiple downstream paths (see Figure 3-2)
`to both multiple distributors and cable
`systems. For example, the studio could sell a
`“Seinfeld” episode to the WB for certain
`nights in a specific week, and TBS on other
`nights. From each step facing down,the
`metadata can fragment, meaningthere is a
`one-to-manyrelationship at each step of the
`way. This is important becauseat each level,
`a seller can sell to multiple customers.
`However,it would be inconvenient to have
`to re-record and re-master content each time
`
`With the twodistinct types of metadata,
`appropriate software will be required to
`author and controlits creation. A key
`ingredient is a uniqueidentifier used to tie
`the asset together with both forms of
`metadata.
`
`1. Content Metadata
`
`The content specific metadata is created
`at the earliest possible point in the
`production and distribution chain. The best
`place for this is at the studio or encoding
`provider. In cases where the contentis
`broadcasttelevision, the content metadata
`could originate from the television network,
`or other production company supplying the
`network feed.
`
`2
`
`~
`
`ific met
`
`The rules-specific metadata can be
`created and adjusted at any point in the
`production and distribution chain, but would
`typically be originated at the same point the
`content is generated. Forlive television
`events, the rules could and should precede
`the actual content transmission. By sending
`the rules ahead first, the STB EPG can be
`populated, or other similar guide related
`decisions can be made.
`
`Propagating Metadata
`
`Both forms of metadata need to be sent
`along the same path as the actual content.
`
`DISH Ex. 1064, p. 11
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`hasa limited availability window. Whenthis
`type ofrule is implemented,it is important
`that the system remove such content and
`make the storage and streaming space
`available as quickly as possible. Another
`situation where the propagation ofcontentis
`important is when a known high-
`concurrency program arrives and needsto be
`propagated to manyplaces in a large
`networkto facilitate the expected high
`demand.
`
`CONCLUSION
`
`Whenanypiece of content is sold or
`distributed downstream, the content
`metadata is included with the actual content
`along with an edited copyof the rules-
`specific metadata. Every copy of
`downstream content could have a uniqueset
`of rules-specific metadata, but the content
`metadata would stay the same. This allows
`each downstream provider to receive
`different rules, and allows them to be
`changed at a later time. Whenthe rules
`change only the rules-specific metadata need
`be resent, not the content metadata or the
`entire program content. With this approach,
`any distributorin the chain can revise and
`update their rules-specific metadata as
`
`Enforcing Rules-
`
`ific me
`
`1. Asset Distribution
`
`To make this system viable, each video
`serveror file server along the asset
`distribution path must receive and obey rules
`encoded in the metadata. Typically in the
`role of asset distribution, all that is required
`is to pass-on the rules given to us. At any
`point in the path, the rules can be edited to
`become morerestricted, but never less
`restricted. As assets are moved downstream
`to the cable plant, appropriate TOD software
`will pick-up the rules-specific metadata. The
`TOD software will use this rules-based data
`to build the availability matrix of programs,
`and associate a local time-slot for the
`consumer. The TODserversoftware is then
`responsible for ensuring that the
`studio/distribution/network rules and
`permissions are obeyed.
`
`In this paper, we have examined how
`conventional VODservers are limited in
`their ability to ingest content and support the
`increasing stream requirements of TOD.
`There is a considerable impact in the output
`stream count as a VODserveris asked to
`ingest more content. With mostexisting
`systems, there is a non-linear loss of
`streaming capability while ingesting content.
`Specifically, many output streams may be
`lost for each single stream ingested. As the
`numberoftitles increases in VODlibraries
`the problem becomes more and more
`apparent. To reduce the impact on a VOD
`server, ingest of new content can occur
`after-hours. Howeverthis is just a temporary
`solution and won’t scale as ingestion
`requirements continueto increase. With the
`upcoming everything on demandrevolution,
`including Television on Demand, the ingest
`limitation of existing VODserver
`architectures becomescatastrophic. The
`more bandwidth consumedby ingest, the
`less bandwidthis available for streaming
`functions, Therefore more servers are
`required to keep the same stream count. As
`more servers are added, ingest and
`
`propagation becomes more and more
`complex. Elaborate ingest servers with
`content propagation services are a short-
`term solution but problematic longer term as
`
`2.ContentPropagation
`
`Whenpropagating content throughoutthe
`cable system, there can exist spe