INGEST & METADATA PARTITIONING: REQUIREMENTS FOR
`TELEVISION ON DEMANDTM
`
`Robert G. Scheffler, Chief Architect
`Broadbus Technologies, Inc.
`
`ABSTRACT
`
` On demand video services, such as
`today’s Video on Demand (VOD),
`Subscription Video on Demand (SVOD), and
`the fast-approaching Television on
`DemandTM (TOD®) are enhancing the
`consumer television experience and creating
`new, exciting revenue opportunities and
`increased cash flow for 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 of 3%-10%
`with limited marketing and promotional
`support. With recent trials of SVOD and an
`increased number of popular titles,
`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,
`subscription-based content, and the most
`popular broadcast content. 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.
`
` 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
`
`asset distribution, content propagation,
`network loading, metadata and rules issues
`need to be addressed to make Television on
`Demand a commercial reality.
`
` This paper will address the issues and
`requirements associated with server ingest
`of broadcast content and content
`propagation. It will also discuss the
`architectural implications for the VOD
`server and propose a new class of server to
`support TOD requirements. The paper will
`also discuss how TOD content is managed
`through the creation and distribution of
`enhanced metadata formats in an
`environment that is controlled by studios,
`distributors, and cable operators.
`
` New video server architectures and
`rules-based content control and propagation
`systems become integral contributors to the
`success of future on-demand services.
`
`VOD/TOD CONTENT INGEST
`
` The issue of the ingest of broadcast
`television content is one that will become
`more and more important for advanced
`video services such as Television on
`Demand to become a 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
`
`DISH Ex. 1006, p. 1
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`II;
`
`support ever increasing content libraries and
`stream counts. However it is important to
`00 at t e evo utlon o VOD arc 1tectures
`(—FO E - (DHUJFF :3:{:5
`
`ow t ose requlrements w1
`
`hange in the future.
`
`<OD 111 t 1e Past
`
`In t 1e ear y ays o VOD, mov1es were
`"oo1str1ute o11 tapes. T ese tapes were
`1ppe
`to eac
`s1te t at requn‘e
`a spec1 c
`m5 (D5O o - B
`H53 (D 0 9° U9 \]
`(m
`(to
`
`-5505 <H(D FF5 F” CI[/3 H5
`
`ops an an average n1ov1e engt o 100
`n11nutes, t e tota Slze o eac
`n1ov1e was
`
`to 3,000 customers to access a library of 150
`to 300 movies. As a result, shipping tapes to
`VOD enao e
`ea —en s
`as proveo to oe a
`ogistical challenge and has evolved to a
`I
`I
`:5_
`(D2(D’1 55 (D O m (D
`m{3
`O N(-FO
`E(-FO
`, w ere
`oy pr1vate roa cast to
`SD*‘1HD("D*‘1(I) <D—l
`‘EQ.D—lO 83H H.OD
`a
`’13
`satellite (see Figure 2-2). With increased
`1orary Slzes, 1ncrease
`stream counts an
`H(D
`
`
`
`00
`to focus on the in est
`rocessing capacit
`functions. This was very labor intensive
`
`'~<
`
`a s1ng e operator ee mg tapes a11o
`w1t
`e11ter111g ru es to 111struct t1e STB gul e
`software about the pricing and availability of
`new titles (see Figure 2—1). Keeping up with
`ontent ingest was quite manageable for the
`operator an t e conventlona VOD server.
`
`i!is
`
`VOD To a
`
`5
`
`As an industry, VOD has matured
`ooeyon t1e s1mp 1st1c examp e eoscr1eo
`nove. VOD 1nsta atlons now enao e 1,000
`
`roughly 2.4 GBytes. A typical installation
`might contain a library of under 100 movies
`and was capable of streaming to less than
`1,000 subscribers simultaneously.
`
`igure 2—] Content Ingestfor VOD in the
`
`In early VOD deployments, n1etadata or
`other business rules weren’t typically
`supphed with the content. The operators
`1e1nse ves were respo11s1o e o1ooe01111g
`
`w1at ru es app 1e
`
`to partlcu ar content am
`
`for e11te1 111g the appropr1ate rules 111to the
`VOD sewer or contro system T 1s
`relat1vely s1n1ple model meant that most of
`the attention was focused on the bllllng
`| 1ter aces set top oox (STE) 0 lent, a11o
`ea —e11oco11tro W1t
`ow stream counts,
`
`movie titles could be loaded dur1ng off-peak
`hours when the VOD server had more
`
`ontent 1s
`1str1oute
`*‘1‘2dOH("D (I)H9.3,H.OD(/1 SD5Q.
`
`(/1
`
`5—i
`
`1verse supp 1ers sen mg ata,t e
`istribution and propagation of content has
`shown itself to be quite a challenge. Content
`an still arrive on tapes and is caught by
`atchers along with trailers, posters, and
`rules that are required to put it all together.
`
`ape Oere
`1.:-
`
`'erson
`
`igure 2-2 Content Ingest, 0r VOD t0 ay
`
`ontent aggregation companies have
`risen to the challenge by offering services to
`edit, adjust, and compile these diverse
`formats and metadata into a nice bundled
`
`II H v. BBiTV
`
`

`

`package to be pitched and caught. However,
`nu amenta pro en1 1s t at w 1 e quite
`
`ept at ow-vo un1e streaming,
`
`large amounts of content propagation. To
`I1ow 1a11o e t1e 111gest o a s1g111 c1ant
`amount 0 content, a conventlona VOD
`
`onventlona VOD servers usua y ac
`
`1n
`
`erver w1
`
`typica y ose some, or n1uc 0
`
`1en~ a1 1ty to s1muta11eous y 111gest arge
`nuantltles 0 content. T e s1tuat1011
`
`ts streammg per ormance.
`
`nu t1p 1es 1tse
`I
`
`as we a
`
`streams, serv1ces,
`
`torage, an egm to 1str1 ute more
`
`1ave PVR functionality during broadcast
`
`access1- e. One way to ma e t1e content
`accessible is to add an ingest server or
`ropagation server at the point where the
`ontent is caught or loaded from tape. This
`'11gest server could then locally store the
`ontent, making it available to the rest of the
`ervers. A ternat1ve yt e ingest server cou
`e used to propagate or distribute the
`ontent to the streaming servers, whether
`oca or remote (see Figure 2—3,
`.
`' emem-ermg t1at t1e streammg servers are
`rimarily intended for streaming there is a
`Ch><('0Q. S8E:1 0 7—07 CT8p)Q.21—Q.E 93<93L93CT1—('0 O*‘1
`
`1ar ware tn‘oug 1out t e networ .
`
`iom-1n1n_ SVOD w1t 1 VOD
`
`Subscription VOD (SVOD) increases the
`ex1st1ng VOD content 1rary uy ac omg 50—
`| 00 movies and other content and making
`hem available to an increased number of
`UIISCI‘ICI’S. Even w1t
`a 1m1tec amount 0
`
`ontent o ere , tr1a s o SVOD to oate 1ave
`
`I esulted in inc1 eased concurrency rates that
`nay ne as
`1g
`as 10%—20% or 3,000 to
`,000 streams in a typical system.
`
`1ese concurrency rates p ace
`
`remen ous eman s on t e streammg
`apacity of the network. Also as stream
`ounts 111crease, so oest e pro em 0
`
`ontent ingest. To increase the stream count,
`dditional streaming servers are required.
`hese additional servers need access to the
`_
`
`1rary o 111gesteo content. I a given p1ece
`o f content is to be made available to every
`ustomer 011 t 1e networ , t e content neeo
`
`U)
`
`o ne e1t er oca y store or remote y
`
`un1erous c anne s o
`
`roacast content to
`
`onventlona VOD servers creates a mass1ve
`1ar ware an. so ware 1n astructuret at
`
`a es up a ot 0 space, consumes a 0t 0
`
`ower, and is inherently less reliable.
`
`igure 2-3 Content Ingest/or VOD in the
`uture
`
`ilielevision on Demand usin; Conventional
`
`ow let’s look at an example where we
`Xpand the VOD/SVOD service offerings to
`11c use Te ev1s1on on Deman (TOD). TOD
`
`9("D 1—3:3:.|
`
`es ca e operators to prov1o e 011
`
`VI
`,"U_U‘
`
`c emand delivery of live or pre-recorded
`U‘H O :3:CLC :3:mFr Fr (D_.(D<._.m ._.O {:5 m 0>1<.—o ('D m mm
`('D ._.._. m [/1
`PF{27‘('D
`
`nov1e an: sun-scrlptlon—ase contentt at
`
`OD/SVOD offers. TOD is especially
`attractive to television content owners
`
`ecause 1t a ows t1e V1ew111g an: sa e o
`
`c
`0 er pro grammmg t1at 1s out o
`yndication. TOD enables the consumer to
`
`

`

`television viewing without requiring a hard-
`rive in t e STB. At a minimum a TOD
`
`system s 1011 o ue capa- e o storing 1,000
`n1ov1es or VOD SVOD customers, p us
`
`10,000 ours 0 capture: roa cast
`elevision.
`
`With Television 011 Demand, ingestion,
`ropagation, and streaming of content needs
`0 occur such that the customer still feels
`
`ike they are watching broadcast television.
`11 ac Mon to t e p et ora 0 content,
`
`railers, posters, and rules that VOD/SVOD
`U3
`
`requirement for low latency content
`
`as:aa5g£0 '(—F Oc23S
`
`E.5<O oiQ8Qm oéUBm('D '~<51%('DB5/3
`
`0111p ete w1t 1 catc 1ers, tape or1ves, an.
`
`ontent ingest propagation now have to
`support the ingestion of broadcast television
`ee s (see Figure 2—4). T 1e pat 1 o t1e
`broadcast feed to the broadcast ingest server
`u
`0 the ingest and propagation server to the
`('D{:5 (-1»O (-1»
`('D OCU3(-1»OED-i UJ HUJ E1—3
`<OU U3('DH<('DH m{:5
`(-1»
`
`ta e many secono s an
`perat10nt1at w1
`p—
`nust occur at the same time as the
`
`Bmadcasl Feed
`
`"
`
`,1/1'
`
`*1/71
`
`“CS
`
`ropagation servers. This solves the content
`ngest and propagation problem presented
`y TOD. However, a hierarchical approach
`0 storage is also required for off-line
`
`Figure 2-4 Content Ingestfor TOD using
`
`01181111161~ concurrency rates OI~ TOD
`w1 require a muc
`1g 1er stream count t an
`he current growth projections for VOD
`
`nee e
`is a 1str1-cute storage strategy w1t
`shared local storage as well as shared remote
`storage that decouples the streaming
`nctions Iomt e storage 111ct10ns. By
`"ecoup 111gt ese
`111ct10ns, stream—count
`and storage—size can be scaled independentl
`while storage can be placed in the network
`
`fferings. When VOD, SVOD, and TOD are
`ombined a typical system may require
`0,000 to 40,000 s1mu taneous streams. For
`
`examp e, us1ng conventiona VOD servers
`apa e o 500 streams eac 1 wou a requlre
`:0 servers to satisfy the stream requirement.
`owever, as more conventiona VOD
`
`servers are a a ea , t1e pro - em 0
`ropagating the content to all the servers
`:36OH('Dm m (Dm 2
`)—J(D B(D(D -
`E1—3 - OH(D.91 (D(/1 Fr
`OB92:? H:3:
`"C
`'~<
`for more ingest servers to propagate the
`ontent so that eventually there is a
`
`1erarc y o ingest servers to streamlng
`ervers. A conventiona VOD server is
`
`[/3_
`
`esigned for streaming to customers, not for
`E S5
`9‘3
`'
`propagating and ingesting
`elevision content. Therefore today’s VOD
`|
`severs are not t e optimum so ution or t
`is
`ompelling, new application.
`
`D with TOD servers
`
`e cr1t1ca issues t at must ue ac resse
`
`o a equate y support TOD are contenti
`B
`('D U3(—F msQ. U3(—FH('DmB O ,9v—‘E > s('D2 O _m U3 U3 0
`f
`(m
`
`I
`
`OD server is required that can ingest
`ozens o c 1anne s o roa cast te ev1s1on
`
`housands of streams with zero—latency. The
`e ays can ue remove uy
`
`t
`
`a irectly into a TOD server where they can
`
`mHCDOr,a:S?9’‘DaO('0a:aoBoS,m93D—a‘f5'7('6('DCLCL5'mCe“5”EHEH.b5"“gco m
`
`ne n‘ect y streameo to customers w1t out
`1erarc y o
`
`I
`
`HF"(-1»a:daa.2Dm:1.cso_55-9050o51’.B.
`<"U‘OQU) <OQ1% Oo OOa ("Da $30 a g,5},
`
`

`

`requirements.
`
`lbsIiiQ
`
`ummar of Content Streams and In est
`
`‘ s needs grow and new business model
`.re introduced, the capacity and scaling of
`VOD streamlng servers are e111g teste .
`ontent 1 rarles are 1ncreas1ng an: greater
`
`S
`
`oncurrency 1s ea mg to 11g 1er an: 11g 1er
`
`tream counts see F1gure -). W1t 1 t 1e
`('D :39 . . ('D .
`‘
`p
`a 1 1ty to
`
`_(I)E,>— O o COF,._.9t.) O H O ”U (-P
`55:5”(IQeggm53"“m553805gm Esg5
`
`roa cast te ev1s1on w1t 1 ow— atency
`:3:
`(DE»S (D
`U)5’0%
`
`g:55.as'(D
`
`onventlona VOD servers are e111g
`l
`axe to t1e 1m1t w1t 1 011 y a moo est 1rary
`1a11ge rate per mont 1.
`‘ s content 1rarles
`
`_row, to prevent 1-rar1es om necomlng
`‘sta e w1t 1 o a content, an Increase
`
`"aeman 1s e111g p ace on o - 1ne 111gest.
`ven now, conventlona VOD servers are
`
`reac 1mg t1en~ 1m1ts 111 e111g an e to eep up
`
`w1t SVOD an VOD app 1cat10ns.
`
`' egar ess o 1ow muc 1 streamlng
`
`eglns to
`ro 1 crate, t e ca e operator w1
`e orce
`
`’"a:H9:F635PmHUJ FE>% .1OaU c (—F D—5
`
`UJFF 95
`
`55""38(to(ma("D('Ds:aa5p—t(—F03aB93('Ds.mEDU3[Tl.—
`
`where it can be used in the most cost—
`
`.a ance etween 1ar ware an transport
`
`e-r
`
`c ange,
`osts. As t e nee s o t e networ
`16 p acement 0 system components can
`1a11ge as we .
`
`Content Storage
`
`F1gure
`
`-5
`
`ontent Ingest or T OD us1ng
`TOD servers
`
`‘ an e arc 1tecture t1at can 1a11o e
`
`ow- atency 1ve-1ngest as we as p1tc er-
`
`atc er an tape ase c-1str1ut10n n10 e s
`
`VOD, an TOD are epen ent on a new
`.rchitecture where scale can be controlled
`
`.nd each environment can be tailored for
`
`eao—en contalnlng
`ect1ve way. A master
`-
`. pooled storage library would allow a group
`of servers to access lesser—used programs
`without requiring local copies. By using this
`istributed storage architecture, each type of
`ontent can actually be moved and
`051tlone 111 t 16 networ{ ort e per ect
`
`"U
`
`
`
`0 an c an 1t10na servers Just to an e
`U3
`(m
`k<
`
`w1 not a equate y an ress t1e pro o em 0
`
`roa cast 111gest to streamlng atency. T 16
`
`ear y super1or so ut1on 1s to use a new
`ass 0 specm 1ze TOD server capa e o
`.
`
`ect y streamlng w1t no
`ercelva e ce ay.
`
`

`

`Application Movie
`Library
`150-300
`200-400
`1,000
`
`VOD
`SVOD/VOD
`TOD/SVOD
`VOD
`
`Library
`Change
` 15/month
` 40/month
`100/month
`
`Concurrency
`Real-Time
`Rate
`TV Ingest
` 0 streams 5%-10%
` 0 streams 10%-20%
`100 streams 30%-65%
`
`Stream
`Count
`1,000-3,000
`3,000-6,000
`20,000-40,000
`
`Figure 2-6 System Capacities for VOD, SVOD, and TOD
`
`METADATA AND CONTROL
`
`Rules are needed
`
` 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. What keeps content flowing from
`creators to consumers is the execution and
`enforcement of detailed contracts. These
`contracts determine the rules of “how”,
`“when”, and “by whom” content may be
`viewed. Whether it’s a re-run episode of
`“Friends” that airs in syndication on TBS or
`a live broadcast of the New York Knicks on
`ESPN 2, there are specific contract-based
`rules that govern the manner in 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 business that
`combines broadcast television content with
`on-demand content.
`
` When VOD was initially deployed, the
`rules were relatively simple. MSOs would
`license a window of time when a movie
`would be made available to its subscribers.
`During the licensing window, the movie
`would be placed on the VOD Server and be
`available to subscribers. After the window
`
`was over, the movie would be deleted from
`the server. A set of rules, or metadata,
`capturing the pre-negotiated License
`Window Start and End Times would be read
`and enforced by the VOD server.
`
` As the industry moves towards SVOD
`and ultimately TOD, the same set of
`complex rules and attributes must be applied
`to each piece of content. Examples of
`additional rules for handling television
`content could include:
`• 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
`• Trick-mode rules and attributes
`(specific speeds, enabled/disabled
`functions)
`• 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 many levels. Examples include:
`• Content owner or studio
`• Studio distribution arm
`• Content aggregator
`• Television network
`• Local television station
`
`DISH Ex. 1006, p. 6
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`• Cable MSO
`• Cable local unit
`Some of the rules apply to VOD, some to
`SVOD, and some only to TOD. The key is
`that there are many rules that can come from
`any number of places. While it can seem
`daunting, it is quite easy to create and
`manage these rules.
`
`title, rating, description, time, actors,
`directors and crew, category, trailer file
`names, poster file 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 content file and would stay with the
`file no matter where it goes.
`
`Partitioning Metadata
`
`2. Rules-specific Metadata
`
` 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 of the rules necessary to
`describe how on-demand content is to be
`handled. Initially written to support VOD
`(movies), it has 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 broadcast television.
`
` Some metadata rules pertain to the
`specific content itself, while others apply to
`how that content is 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
`content itself, and the distribution specific
`metadata was separate, then the same
`content with metadata attached could be sent
`to many locations, with a different version
`of the distribution metadata. Thus, the
`content metadata and the rules-specific
`metadata has been partitioned.
`
`1. Content Metadata
`
` Content metadata includes program
`specific things such as a unique identifier,
`
` 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
`passes those rules along to the content
`distributors. For example, there may be a
`requirement to 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 Monday through Friday
`anytime, but not Thursday from 8-9 pm, to
`prevent intruding 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 want to restrict viewing from 10-11pm
`during the local news hour.
`
`Figure 3-1 Rules-specific Metadata Flow
`
`DISH Ex. 1006, p. 7
` DISH v. BBiTV
` IPR2020-01280
`
`

`

` At each step along the way, the rules can
`become more restricted, but cannot be 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 obey the rules it passes on.
`When they reach the cable system, the TOD
`menu or 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 each step 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, meaning there is a
`one-to-many relationship at each step of the
`way. This is important because at 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
`
`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.
`
`Creating Metadata
`
` With the two distinct types of metadata,
`appropriate software will be required to
`author and control its creation. A key
`ingredient is a unique identifier 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 content is
`broadcast television, the content metadata
`could originate from the television network,
`or other production company supplying the
`network feed.
`
`2. Rules-specific metadata
`
` 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. For live 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. 1006, p. 8
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`When any piece of content is sold or
`distributed downstream, the content
`metadata is included with the actual content
`along with an edited copy of the rules-
`specific metadata. Every copy of
`downstream content could have a unique set
`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. When the rules
`change only the rules-specific metadata need
`be resent, not the content metadata or the
`entire program content. With this approach,
`any distributor in the chain can revise and
`update their rules-specific metadata as
`necessary.
`
`Enforcing Rules-specific metadata
`
`1. Asset Distribution
`
` To make this system viable, each video
`server or 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 more restricted, 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 TOD server software is then
`responsible for ensuring that the
`studio/distribution/network rules and
`permissions are obeyed.
`
`2. Content Propagation
`
` When propagating content throughout the
`cable system, there can exist specific rules
`related to perishable content, or content that
`
`has a limited availability window. When this
`type of rule 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 of content is
`important is when a known high-
`concurrency program arrives and needs to be
`propagated to many places in a large
`network to facilitate the expected high
`demand.
`
`CONCLUSION
`
` In this paper, we have examined how
`conventional VOD servers 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 VOD server is asked to
`ingest more content. With most existing
`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
`number of titles increases in VOD libraries
`the problem becomes more and more
`apparent. To reduce the impact on a VOD
`server, ingest of new content can occur
`after-hours. However this is just a temporary
`solution and won’t scale as ingestion
`requirements continue to increase. With the
`upcoming everything on demand revolution,
`including Television on Demand, the ingest
`limitation of existing VOD server
`architectures becomes catastrophic. The
`more bandwidth consumed by ingest, the
`less bandwidth is 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
`
`DISH Ex. 1006, p. 9
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`unacceptable latencies are introduced to the
`distribution of broadcast television.
`
` A new breed of servers designed
`specifically for Television on Demand is
`required. These servers need to handle over
`100 streams of live ingest while
`simultaneously redistributing the ingested
`content to over 20,000 output streams. The
`server must not suffer any performance
`degradation in output streams while
`ingesting live or non-live content. The
`latency through such systems must be low
`enough to enable live television with trick-
`mode functionality similar to that of DVD.
`The streaming elements and the storage
`elements must be separately scalable and
`movable within the network.
`
` With the plethora of ingested content
`from VOD, SVOD, and TOD, new means
`for authoring and propagating metadata
`must be implemented. In addition to content
`metadata, a new class of rules-based
`metadata will be required to protect revenue
`streams by allowing a rules-based
`distribution and STB presentation of
`content. The metadata must be partitioned
`
`and carried separately from the actual
`content to allow updating as well as
`customization depending on the MSO and
`region that the content is destined for.
`
` A new breed of specialized, high
`performance TOD server with low-latency
`and live content ingest capabilities, plus a
`new metadata methodology, is a requirement
`to realize the potential of Television on
`Demand for cable operators.
`
`About the Author
`
`Robert Scheffler is Chief Architect at
`Broadbus Technologies, a provider of next-
`generation server systems that enable cable
`operators to effectively scale and migrate
`their networks from Video on Demand to
`Television on DemandTM – (TOD®)
`
`Robert can be reached at:
`
`(978) 264.7900
`Robert.Scheffler@broadbus.com
`http://www.broadbus.com
`
`TOD and the Broadbus logo are registered trademarks of Broadbus Technologies, Inc. All rights
`reserved. Other trademarks used herein are property of the respected companies.
`
`DISH Ex. 1006, p. 10
` DISH v. BBiTV
` IPR2020-01280
`
`