DSTAC WG4 Report
August 4, 2015
REPORT OF WORKING GROUP 4 TO DSTAC
Introduction
Working Group 4 (WG4) was formed out of the larger DSTAC to address the topic of device platforms,
variability, and interfaces.
Guidance Description
(Part I) The working group will identify existing devices and technologies that receive MVPD and OTT
service, such as DVRs, HDTVs, personal computers, tablets in home, connected mobile devices, take-
and-go mobile devices, etc., and identify the salient differences important to implementation of the
non-security elements of a system to promote the competitive availability of such devices based on
downloadable security.
(Part II) For each category of existing device identified above, the working group will identify a system
comprising minimum standards, protocols, and information other than security elements to enable
competitive availability of devices that receive MVPD services.
(Part III) The working group may identify alternative systems as appropriate to promote the availability
of different categories of navigation devices, consistent with the Commission’s instruction to
recommend an approach that would allow consumer electronics manufactures to build devices with
competitive interfaces and an approach under which MVPDs would maintain control of the user
interface.
Product
The working group will deliver and present its findings to the full DSTAC.
DSTAC WG4 Report
August 4, 2015
2
Table of Contents
Part I: Existing Devices and Technologies ................................................................................................ 6
Section I: Devices that receive MVPD or OTT service ........................................................................... 6
Section II: Technologies (Network) that enable the reception of MVPD or OTT service ...................... 6
Operator Network Technologies........................................................................................................... 6
Home Network Technologies .............................................................................................................. 27
Section III: Technologies (Functional) that enable the reception of MVPD or OTT service: ............ 36
Gateways and MVPD Provided Devices and Environments................................................................ 36
Application on Retail Device ............................................................................................................... 38
Standalone Retail Devices ................................................................................................................... 40
Section IV: Technologies that enable the reception of MVPD or OTT service: ................................. 41
Google Fiber IPTV System Overview ................................................................................................... 41
Slingbox ............................................................................................................................................... 42
Mediaroom ......................................................................................................................................... 42
Section V: OTT Services .................................................................................................................... 42
Section VI: Essential Customer Experiences ..................................................................................... 43
PURPOSE ............................................................................................................................................. 43
INTRODUCTION ................................................................................................................................... 43
END-USER Precondition: ..................................................................................................................... 44
USE CASE #1 - Tuning and Viewing a Linear Channel ......................................................................... 44
USE CASE #2 - Viewing On-Demand Content ...................................................................................... 54
USE CASE #3 - Tuning and Viewing Pay Per View (PPV) events .......................................................... 55
USE CASE #4 - Navigation .................................................................................................................... 56
USE CASE #5 - Recording Linear Content ............................................................................................ 57
USE CASE #6 - Remote Management by Consumer ........................................................................... 57
USE CASE #7 - Set-Top Box set-up ...................................................................................................... 58
USE CASE #8 - Customer Support and Remote Management by Service Provider ............................ 59
USE CASE #9 - Installation and Provisioning ....................................................................................... 59
USE CASE #10 - Device Operation Requirements ............................................................................... 60
USE CASE #11 – User Authentication .................................................................................................. 61
USE CASE #12 – Renewability (DELETED DURING DELIBERATIONS) ................................................... 62
DSTAC WG4 Report
August 4, 2015
3
USE CASE #13 - Cloud VOD Delivery ................................................................................................... 62
USE CASE #14 - Cloud Live Streaming ................................................................................................. 63
USE CASE #15 – Cloud DVR Recording and Streaming ........................................................................ 63
USE CASE #16 - Cloud Content Downloading for Mobile Devices ...................................................... 64
Part II: Systems that Enable Competitive Availability of Devices ........................................................... 66
Section I: SAT-IP .................................................................................................................................. 66
Description .......................................................................................................................................... 66
Protocols ............................................................................................................................................. 66
Security ............................................................................................................................................... 66
Information ......................................................................................................................................... 66
Section II: CableCARD .......................................................................................................................... 67
Description .......................................................................................................................................... 67
Standards ............................................................................................................................................ 68
Information ......................................................................................................................................... 68
Applicable Devices .............................................................................................................................. 68
Section III: DRI and OpenCable interfaces (and specifications) ........................................................ 69
Description .......................................................................................................................................... 69
Protocols ............................................................................................................................................. 69
Security ............................................................................................................................................... 69
Information ......................................................................................................................................... 70
Applicable Devices .............................................................................................................................. 70
Section IV: Android/iOS Store Device Architectures from DEVELOPER Point of View ..................... 70
Standards ............................................................................................................................................ 72
Protocols ............................................................................................................................................. 73
Information ......................................................................................................................................... 74
Applicable Devices .............................................................................................................................. 78
Section V: VidiPath ........................................................................................................................... 78
Summary ............................................................................................................................................. 79
VidiPath Deployment Scenarios .......................................................................................................... 91
Standards ............................................................................................................................................ 93
Protocols ............................................................................................................................................. 94
DSTAC WG4 Report
August 4, 2015
4
Information ......................................................................................................................................... 94
Applicable Devices .............................................................................................................................. 95
Section VI: W3C HTML5 Web Browser.............................................................................................. 95
World Wide Web Consortium (W3C) Standards ................................................................................. 98
Protocols ............................................................................................................................................. 99
Information ......................................................................................................................................... 99
Applicable Devices .............................................................................................................................. 99
Section VII: RVU™ ............................................................................................................................... 99
Standards .......................................................................................................................................... 100
Protocols ........................................................................................................................................... 100
Information ....................................................................................................................................... 101
Applicable Devices ............................................................................................................................ 101
Section VIII: Passage .......................................................................................................................... 101
Description ........................................................................................................................................ 101
Passage Headend Encoding .............................................................................................................. 102
Passage Technology .......................................................................................................................... 103
System Architecture .......................................................................................................................... 105
Managing Bandwidth ........................................................................................................................ 105
Implementations ............................................................................................................................... 106
Security ............................................................................................................................................. 106
Protocols ........................................................................................................................................... 106
Part III: Alternative Systems that Enable New Categories of Navigation Devices ................................. 107
Section I: “Competitive Navigation” System..................................................................................... 107
Competitive Navigation Device Executive Summary ........................................................................ 107
Diversity in Direct Connection Delivery Networks ............................................................................ 109
Migration to IP Delivery Underway .................................................................................................. 110
Limitations of Architectures Thus Far ............................................................................................... 111
Limitations Where User Experience Is Too Closely Controlled ......................................................... 112
Interfaces Necessary to Enable Competitive Interoperability .......................................................... 113
Physical Interconnection and Basic Networking ............................................................................... 115
Service Discovery Interface ............................................................................................................... 116
DSTAC WG4 Report
August 4, 2015
5
Entitlement Information Interface .................................................................................................... 119
Content Delivery Interface ................................................................................................................ 120
Use Case Analysis .............................................................................................................................. 122
Closing and Summary ........................................................................................................................ 126
Section II: “Application-Based Service with Operator Provided User-Interface” System ................. 127
Introduction ...................................................................................................................................... 127
Device Specific Apps ......................................................................................................................... 130
HTML5 Web Apps ............................................................................................................................. 135
DLNA VidiPath™ ................................................................................................................................ 138
RVU™ ................................................................................................................................................. 139
Virtual Joey ........................................................................................................................................ 139
Sling Media Technology Clients ........................................................................................................ 140
Use Cases Supported ........................................................................................................................ 140
Section III: Implementation Analysis .............................................................................................. 144
Evaluation of “Competitive Navigation” System Proposal by Proponents of Application-Based
Service ............................................................................................................................................... 144
Evaluation of “Application-Based Service with MVPD UI” (“Apps Approach”) by Proponents of
Application-Based Service ................................................................................................................. 166
Passage to Facilitate Transition to All DRM Approach ...................................................................... 174
Policy Analysis by Content Providers ................................................................................................ 177
Evaluation of Both Proposals by Proponents of “Competitive Navigation” Proposal ...................... 178
Part IV: Appendix A: Survey of Existing Devices .................................................................................... 201
DSTAC WG4 Report
August 4, 2015
6
Part I: Existing Devices and Technologies
“The working group will identify existing devices and technologies that receive MVPD and OTT service,
such as DVRs, HDTVs, personal computers, tablets in home, connected mobile devices, take-and-go
mobile devices, etc., and identify the salient differences important to implementation of the non-
security elements of a system to promote the competitive availability of such devices based on
downloadable security.”
As most members generally understand the functionality of the devices listed in Part I, it is expected
that information would be provided as to how the devices discover and receive content.
As content is coming in on different input ports and through different applications running on the
devices, the mechanisms for each are detailed.
Various points have been captured in the table in Appendix A: Survey of Existing Devices.
Section I: Devices that receive MVPD or OTT service
The table in Appendix A serves as a reference for retail and MVPD devices that will interact with content
distribution networks, and provides basic descriptions of their functionality. Many of these devices will
function as receivers for MVPD/OTT content, and it is important to understand their differences and
capabilities for the purpose of establishing standards for the reception and control of video content. All
of these devices may connect through disparate network architectures such that protocols for device
management and stream management need to be considered and how these devices receive and
display content.
Section II: Technologies (Network) that enable the reception of MVPD
or OTT service
Discussion of important features of specific technologies
Operator Network Technologies
SUMMARY
As noted in WG2 Report Section III starting on page 3 [45], there is variation in current video providers’
distribution technologies and platforms. Across all service providers, an approach that has developed
for delivering video service to customer owned devices is through “apps.”
Diversity of Access Network Technologies
As noted in WG2 Report in Section III starting on page 4 [45], the larger US Cable operators and Verizon
mostly use one or both of two the two primary CAS (Conditional Access Systems) vendors, and all
support CableCARD for limited services. Both US Cable and Verizon use Quadrature Amplitude
Modulation (QAM) for broadcast signals while over Hybrid Fiber Coax (HFC) or B/GPON (Broadband-
/Gigabit-capable Passive Optical Networks) fiber networks. Verizon adds hybrid QAM/IP for on-demand
content and two-way services. Direct Broadcast Satellite (DBS) also has two major variants for transport
DSTAC WG4 Report
August 4, 2015
7
and CAS. AT&T uses IP unicast and multicast over DSL or B/GPON fiber, with a Digital Rights
Management (DRM) approach instead of CAS.
Diversity Of Customer Equipment Installation, Provisioning, And Configuration Methods Error!
Reference source not found.
The diversity of network technologies across and within MVPDs is associated with a diversity of
Customer Premise Equipment (CPE) installation, provisioning, and configuration methods. Table 1 -
Diversity of MVPD Customer Premise EquipmentTable 1 shows the equipment necessary for network
termination at the premise, the CPE deployed for the Pay TV service and the technologies used for in-
home distribution of the service.
MVPD
Network Termination
Customer Premise
Equipment (CPE)
In-Home
Distribution
Cable
Coax & RFoG Optical
Network Termination
(ONT)
DVR & Non-DVR set-tops,
DTA and Cloud Based
systems
IPTV Set tops
Cable RF & MoCA
Wi-Fi
Satellite
Out Door Unit (ODU) –
Satellite Dish
Low noise block down-
converter (LNB )
Multiswitch (RF
switching unit)
Genie Server (DVR) &
Genie Mini clients
Hopper (DVR) & Joey
clients
802.11 & MoCA
MoCA
Wi-Fi
Telco
VDSL Modem or
Gateway
B/GPON Optical
Network Termination
(ONT)
DVR & Non-DVR IPTV set-
tops
802.11
Cable RF & MoCA
Wi-Fi
Google
Fiber TV
GPON Optical Network
Termination (ONT)
Network Box, Storage Box,
TV Box
802.11 & MoCA
Table 1 - Diversity of MVPD Customer Premise Equipment
Cable networks are typically terminated at the house at the point of entry with coax cabling. In some
instances cable networks use RF over Glass (RFoG), an analog RF fiber to the premise technology. The
DSTAC WG4 Report
August 4, 2015
8
RFoG Optical Network Termination (ONT) converts the optical RF to an electrical RF signal over coax
permitting the use of traditional cable QAM based CPE. Cable systems make use of both DVR and non-
DVR set-top boxes that receive broadcast signals and use MoCA technology to link them together for a
whole home DVR solution.
Satellite networks terminate in Out Door Units (ODU) satellite dishes. Low Noise Block down-converters
shift the satellite signals to a frequency band that can be switched by a Multiswitch unit and distributed
via coax cables to the various satellite CPE. Satellite systems make use of both DVR and non-DVR set-
tops and use both MoCA and 802.11 Wi-Fi for distribution in the home for a whole home DVR solution.
The satellite MVPDs also have client software available in some LG, Samsung, Sony and Toshiba TVs that
allow them to access services through their home network either using RVU or Virtual Joey technology.
Telco networks are typically either traditional telephone twisted-pair copper or B/GPON FTTP networks.
In the case of twisted-pair, the network is terminated by a VDSL modem or gateway in an IPTV solution
making use of both DVR and non-DVR IPTV set-tops and use 802.11 Wi-Fi for distribution in the home
for a whole home DVR solution. Twisted-pair networks also need a filter installed to block the VDSL
signal from telephones in the home. In the case of fiber networks, the network is terminated in an ONT
and, in the case of FiOS, the optical RF spectrum is converted to electrical RF spectrum and distributed
over coax, similar to the cable RFOG case. Fiber networks may use either Hybrid IP/QAM based set-tops
(DVR and non-DVR) and MoCA for distribution in the home for a whole home DVR solution or the same
IPTV based set-tops and 802.11 Wi-Fi distribution as in the twisted-pair case. In Hybrid IP/QAM based
set-tops, each set-top box includes two interfaces: an interface to the overlay wavelength for linear
services and certain control signaling; and an IP interface for IP VOD, widgets, guide data, gaming, and
certain control plane signaling. All of these are integrated into a single service within the set-top box.
While all MVPDs would like for consumers to be able to self-install the necessary equipment to receive
the MVPD service, this is not always a practical option for a number of reasons. First, if this is the first
time a customer has subscribed to an MVPD service, it may be necessary to install the necessary
network termination equipment, whether this is a cable drop, a fiber drop and an ONT, a VDSL
modem/gateway and filters, or a satellite ODU, LNB, and Multiswitch. In addition to this, it may be
necessary to wire the home with coax cable to distribute the signal from the point of entry to the
various rooms in which service is desired. Even if the home has been previously wired for cable service,
the need to insure that signal levels are appropriate or alignment of the satellite ODU is correct is still
required.
Provisioning of set-top boxes also varies across and within MVPDs. There are two basic kinds of
provisioning necessary in an MVPD system. The first is network provisioning so that the set-tops are
properly connected to the network and can communicate properly. The second is provisioning of
entitlements so that subscribers can access the services to which they are subscribed. Network
provisioning is typically specific to the type of network and CAS system deployed, while provisioning of
entitlements is exclusively the domain of the CAS system deployed. Configuration methods are also
specific to the type of network and CAS system deployed.
Common Approaches to Retail Devices
As noted in WG2 Report in Section VI starting on page 12 [45], for some service providers an approach
for delivering video service to customer owned devices is through service provider authored or
authorized “apps.”
DSTAC WG4 Report
August 4, 2015
9
MVPDs are remarkably similar in their approach to supporting retail devices, following the successful
model that OTT video distributors such as Netflix, Hulu, and others use.
Cable Technologies and Architectures [46]
Cable systems have evolved over the decades since the first cable systems in 1940s. Most cable
operators have upgraded their networks to two-way, Hybrid Fiber Coax (HFC). However, this evolution
was not uniform across the United States and there is diversity across cable operators. Figure 33 shows
the typical HFC cable network architecture.
Figure 1 - Typical Cable System Network Architecture
Cable system architectures reflect fundamental differences dating from the original design goals based
on different vendors and different owners. The General Instrument (now ARRIS) design was tailored
primarily for the more rural and less clustered systems owned by Tele-Communications, Inc., with a
focus on increased channel capacity, minimized head-end cost, and centralized set-top control and
authorization. The Scientific-Atlanta (now Cisco) design was tailored primarily for the more urban and
clustered systems primarily owned by Time Warner Cable, with a focus on two-way interactive services
such as Video-on-Demand (VoD), the ability to add applications and services to set-top boxes over time,
and local control and authorization. Thus, even though there are some shared elements, such as MPEG-
2 video compression, there are fundamental differences in technologies for CAS, controllers, the out-of-
band (OOB) communications channels used for command and control of the set-top box, network
transports, QAM modulation, video codecs, core ciphers, advanced system information such as network
configuration, session management, operating system, processor instruction set, interactive services,
billing systems, applications necessary for presentation of services and in the set-top boxes. Error!
Reference source not found.
DSTAC WG4 Report
August 4, 2015
10
The respective design objectives resulted in proprietary systems that had different system architectures
and network configurations, as well as different CAS systems, as described above. Despite these
different design goals there were also a significant number of common elements:
● The GI and SA systems used MPEG-2 video compression and Dolby® AC-3 audio compression
[6][7].
● Both systems have added support for MPEG-4/AVC in the intervening years [8].
● Both systems used QAM modulation for transmission of MPEG-2 transport streams carrying the
audio/video signal [9].
● Both systems used variants of Data Encryption Standard (DES-64) [10] encryption as the working
cipher for their CA systems and in particular both were capable of supporting the SCTE 52 2008
DES-CBC variant [11].
● Both systems used a common Service Information format to communicate channel line-up
information [12].
However, because of the different design goals, there were many proprietary components remaining
in each system.
The proprietary aspects of the two systems largely lay in following areas:
● The CAS system (DigiCipher™ II in the case of GI and PowerKey™ in the case of SA) used to control
subscriber entitlements and manage access to digital channels.
● Their out-of-band (OOB) communications channels used for command and control of the set-top
box:
o GI’s system implemented the DigiCipher II OOB utilizing an MPEG structure for
transporting OOB messaging downstream, standardized as ANSI/SCTE 55-1 2009 [13]. The GI
OOB channel provided 2Mbps downstream bandwidth and 256Kbps upstream bandwidth
through an Aloha, polled communication protocol.
o SA’s system implemented a DAVIC based OOB utilizing an ATM/IP structure for
transporting OOB messaging downstream, standardized as ANSI/SCTE 55-2 2009 [14]. The SA
OOB channel provided 1.5 Mbps bandwidth in both the downstream and upstream using a real-
time, two-way protocol.
● Operating system (OS) and processor instruction set:
o GI’s system initially implemented a proprietary kernel on a Motorola 6800 processor
instruction set.
o SA’s system initially implemented the PowerTV™ OS on a Sun SPARC™ processor
instruction set.
o Subsequently, both system providers have introduced other OS (e.g. Linux) and
processor instruction sets (e.g. MIPS).
● Network control architecture in support of interactive applications, such as VoD and Switched
Digital Video (SDV):
o GI’s network control architecture lacked the concept of an interactive session manager,
requiring third-parties to provide this component when integrating session-based services,
such as VoD.
o Interactive network functions such as Switched Digital Video have been implemented using
external controller platforms, available from 3
rd
parties or directly from ARRIS (Vertasent
and BigBand implemented the most commonly deployed SDV controllers, and were
subsequently acquired by ARRIS).
DSTAC WG4 Report
August 4, 2015
11
o SA’s network control architecture implemented an interactive session manager, supporting
DSM-CC User-to-Network commands [5] for support of dynamic MPEG transport sessions.
● Electronic Program Guide (EPG) application and EPG metadata format.
Integration of interactive service components, such as a VoD application and corresponding video
streaming servers, required tight integration with either GI or SA’s network. This resulted in pair-wise
integrations between VoD vendors, set-top applications vendors, and the digital video systems
providers.
Existing cable systems have now evolved in ways that vary widely from the legacy system architectures
that were just described. One major difference is the use of the Common Scrambling Algorithm (CSA) in
some systems, rather than core ciphers based on DES. In addition, many systems incorporated content
delivery components from multiple vendors, which has led to much more diversity in session control,
bandwidth management, maintenance, commercial insertion, VOD and other critical system hardware
and software.
To attempt to address the issue of interoperability across cable systems, CableLabs developed a set of
specifications under the OpenCable program Error! Reference source not found.. These specifications
isolate the proprietary system specific aspects of these systems into separable components. The
systems specific aspects fall into two general categories:
● Hardware – These included, the core hardware components of the CA system (working cipher and
key hierarchy) and the key components of the OOB communications network (e.g. forward error
correction and MAC layer processing)
● Software – These included, Operating System (OS) and applications (both cable operator specific
and potentially third-party applications)
Figure 2 - OpenCable/tru2way Interface DiagramFigure 2 provides a block diagram identifying the key
interfaces in the OpenCable architecture.
DSTAC WG4 Report
August 4, 2015
12
Figure 2 - OpenCable/tru2way Interface Diagram
The four interfaces specified by OpenCable:
● The Network Interface – This is the interface that connects to the cable network at the
consumer’s home and is specified as part of the OpenCable Host Specification [30].
● The Consumer Interfaces – These are the interfaces that connect to the consumer’s TV or other
entertainment devices (e.g. HDMI, component analog, composite analog, etc.) and are also
specified as part of the OpenCable Host Specification Error! Reference source not found..
● The Conditional Access Interface – This is the interface to the system-specific CA and OOB channel
and is specified in the CableCARD™ Specifications.
● The Application Interface – These are the Application Program Interfaces (APIs) that applications
use to perform the desired functions using the Host and CableCARD components and are specified
by the Open Cable Application Platform (OCAP) specification [23].
In this architecture, an OpenCable Host device is enabled to connect to the cable network by providing a
hardware component, the CableCARD, which is specific to the proprietary system deployed in that cable
network. Originally, this would be either a GI or SA CableCARD; however other CA systems, such as NDS
and Conax, have been added to this list over time. The CableCARD cryptographically binds to the Host
for security and copy protection purposes and instructs the Host how to acquire the OOB
communications channel, register on the network, and receive the OOB command and control signals
appropriate for the CA system. The Host is then able to acquire the list of applications, for example the
EPG, which are supported on the cable system, securely download them if necessary, and begin
execution.
The CableCARD is the hardware module in the OpenCable system that achieves this isolation through a
physical encapsulation of the cryptographic CA component and some portions of the OOB
communications channel. The CableCARD by necessity had to be a separable or removable module that
DSTAC WG4 Report
August 4, 2015
13
could be delivered independently from the Host device. In practice, the local cable operator provides
the CableCARD.
The only commonality the two proprietary OOB channels have is the use of QPSK modulation; they
differed in the frequency band and bandwidth, the Forward Error Correction (FEC), the framing, and the
transport protocol used. Consequently, the QPSK front-end (modulation and demodulation) was placed
in the OpenCable Host and all of the higher layers of the proprietary OOB communications protocol
stack were placed in the CableCARD. Raw QPSK symbols and their timing passed across the PCMCIA
interface through the use of redefined pins in the physical interface. The CableCARD is responsible for
instructing the Host what mode of operation the system requires. OpenCable also enabled the cable
operator to migrate the proprietary messaging carried on these proprietary OOB channels to a standard
two-way communications channel, such as Data-Over-Cable Service Interface Specification (DOCSIS®).
This was accomplished through the DOCSIS Set-top Gateway (DSG) with the appropriate modifications
to the CableCARD Error! Reference source not found.. Since DOCSIS provides an efficient two-way IP
connection for devices, the DSG specification focused on extending the DOCSIS specification to perform
two key functions:
● Encapsulate the downstream proprietary messaging in an IP transport using a broadcast or
multicast transmission so that all set-tops could access it concurrently.
● Provide a one-way mode of operation so that the set-top could continue to function in a one-way
mode in cases of network disruption.
EIA-679 Part B [17] only permitted the decryption and processing of a single MPEG Multi-Program
Transport Stream (MPTS), equivalent to a single set-top tuner. The original CableCARD specification
followed this model with single stream mode, or S-Mode, of operation. As Digital Video Recorders
(DVRs), picture-in-picture, and other multi-tuner features were developed, it was realized that the
original S-Mode CableCARD had inadequate bandwidth for these features. It would require multiple S-
Mode CableCARDs to provide this capability and could not grow to support multi-tuner gateway
scenarios. Subsequently, the M-Mode (or Multi-stream mode) CableCARD specification was developed
and has its origin in SCTE 28 Error! Reference source not found.. M-Mode provides the higher transport
data throughput rates that are required to support features, such as multiple-tuner Hosts, Hosts with
DVRs, and Hosts with picture-in-picture capability as described in DSTAC Working Group 2 Report #1
Error! Reference source not found..
Satellite Technologies and Architectures [52]
As was summarized in DSTAC Working Group 2 Report #1 [45], there are two primary Direct Broadcast
Satellite (DBS) providers in the United States, DISH and DirecTV. While they use similar technologies and
architectures to deliver the DBS portion of their service, there are still sufficient differences in the two
systems as to prevent a set-top box designed for one system from working on the network of the other.
Figure 3 shows the general DBS architecture for distribution of the television signal from program source
to the subscriber’s home. The video programming is distributed from the program source via satellite
(indicated by “a” in the diagram) or fiber (indicated by “c” in the diagram) to the satellite up-link facility
where it may be re-encoded, multiplexed, and encrypted for transmission via the DBS satellite to the
DSTAC WG4 Report
August 4, 2015
14
subscriber’s home. Local Receive Facilities (LRF) or Local Collection Facilities (LCF) are used to receive
programming from local broadcast stations (indicated by “b” in the diagram), where these channels are
then decoded, re-encoded, multiplexed, and transmitted via satellite or fiber to the satellite up-link
facility. In some instances, an antenna at the subscriber’s home receives local broadcast stations
directly (indicated by “d” in the diagram).
Figure 3 - DBS Architecture – Satellite to Home Distribution Path
Multiple satellites are used in each system to carry the diversity of programming offered by each
provider. The Out Door Units (ODUs) and Low Noise Block (LNB) down-converters receive the satellite
signals and down-convert the signal to a lower frequency for distribution over coax cable throughout the
subscriber’s home. Because there are multiple satellite signals received by the ODU and LNB and there
are potentially multiple tuners and/or set-tops in the home, a Multiswitch unit is used to switch the
specific signal source to the requesting tuner.
The two operators’ systems differ in a number of respects, including:
● The number and location of up-link facilities
● The orbital positions of the satellites used by each
● The satellite frequency plans used
● The Out Door Units (ODUs), Low Noise Block (LNB) down-converters, and Multiswitch units
used
● The Conditional Access Systems (CAS) used
● The whole home DVR architectures and technologies used
DSTAC WG4 Report
August 4, 2015
16
Figure 5 - DISH Uplink Facilities
The orbital positions for the two providers differ and this directly affects the orientation of the satellite
dish and configuration of the ODU, LNB, and Multiswitch at the subscriber’s home. The orbital positions
for the two providers currently are:
● DirecTV – 99W, 101W, 103W as well as 110W, 119W & 95W
● DISH – Eastern US Arc – 61.5W, 72.7W, 77W, Western US Arc – 110W, 119W, 129W and
shared 118.7W
The satellite frequency plans of the two providers differ as well. This impacts the configuration of the
LNB and Multiswitch at the subscriber’s home, as well as the implementation of the Integrated Receiver
Decoder (IRD) or set-top box. Figure 6 and Figure 7 show the respective satellite and in-home frequency
plans of the two providers.
DSTAC WG4 Report
August 4, 2015
17
Figure 6 - DIRECTV Frequency Plan
DSTAC WG4 Report
August 4, 2015
18
Figure 7 - DISH Frequency Plan
DSTAC WG4 Report
August 4, 2015
19
The ODUs and LNBs differ depending on the DBS operator and type of service being provided. For
example, the current DirecTV ODUs include: an 18” Round (SD only), an 18x20” Triple-Sat (SD only), or a
Slimline ODU (HD) which can be used with a Slimline-3 or a Slimline-5 LNB. The LNBs also differ in their
powering. DISH LNBs are typically powered by one set-top in the home, while all DirecTV and some
DISH LNBs have a dedicated external power supply. The Multiswitch unit allows a set-top to select
between the multiple input signals received by the LNB. Because LNBs receive signals from multiple
satellite transponders, it is necessary to switch the input signal for the requested channel to the
requesting set-top tuner. The set-top sends a signal to the Multiswitch unit identifying the desired input
and the Multiswitch unit switches the input signal onto the coax cable to the requesting set-top.
The two DBS providers differ in their implementations of their respective Multiswitch units. The control
signaling between the two systems differs. Specifically, DIRECTV uses a Pulse-Width Modulated (PWM)
control scheme; with simple 3-byte messages to identify desired input port, which does not strictly
conform to the DiSEqC (Digital Satellite Equipment Control) standard. DISH uses system based on and
conforming to DiSEqC but extending the standard with additional commands. There are Single Wire
Multiswitch units, which allow multiple, independent set-tops to share a single coaxial cable and multi-
wire switch units that use separate coax cables for each set-top. Set-tops, Multiswitch units, ODUs and
LNBs from the two providers do not interoperate.
The DIRECTV set-top boxes receive SD satellite signals using the 130-byte “DSS” transport format, while
DISH uses the 188-byte MPEG transport format for its SD satellite signals. Both MVPDs use MPEG
transport format for HD satellite signals. The two DBS providers utilize Digital Video Recorders (DVR) in
the home to deliver a more interactive and personalized experience to subscribers: each have
proprietary implementations that leverage MVPD-controlled content storage to deliver features
including VOD and targeted Dynamic Ad Insertion (DAI). Each implementation “pushes” VOD and DAI
content through the DBS broadcast system to pre-allocated storage areas of the DVR. As an example of
use of this capability, the two providers jointly offer targeted DAI that was used during the 2014 election
cycle by local and national candidates to reach their constituents. Each proprietary implementation
required the providers to modify the headend transport and video stream encoding to offer seamless
merging of broadcast and from-DVR content. The set-top boxes from both providers offer common
television outputs (e.g. analog component and composite, digital HDMI), but have deployed non-
interoperable approaches for IP-networked outputs. Software updates to set-top boxes happen
independently on each DBS system as new features of the service are released, and typically range in
frequency from quarterly for legacy devices to more than once per month for newly deployed set-top
boxes or critical bug fixes. The two DBS providers also differ in the CAS and DRM solutions used in their
respective DBS systems. DirecTV uses NDS CAS/DRM systems and DISH uses Nagra CAS/DRM systems.
Both providers support additional DRM systems for their internet-delivered services.
While both DBS providers use a client-server architecture and MoCA for in-home distribution of their
whole home DVR solutions, they differ in their specific implementations. Figure 8 and Figure 9 show the
two whole home DVR server-client solutions. DirecTV uses the RVU Remote User Interface technology,
which has been integrated into a number of retail televisions (see rvualliance.org/products). Like other
MVPDs, both providers participate in the Digital Living Network Alliance (DLNA) and make use of some
DLNA protocols in their whole home DVR solutions.
DSTAC WG4 Report
August 4, 2015
20
Figure 8 - DIRECTV Server-Client Architecture
DSTAC WG4 Report
August 4, 2015
21
Figure 9 - DISH Server-Client Architecture
DSTAC WG4 Report
August 4, 2015
22
Telco Technologies and Architectures
Telephone companies have used a number of different technologies and architectures for delivery of
their MVPD service. Some have partnered with satellite providers to deliver an MVPD service, others
have deployed fiber with an RF overlay network, and others have deployed IPTV systems over VDSL and
fiber networks. This section covers the systems deployed by AT&T and Verizon.
AT&T and Verizon have taken different approaches to deploying an MVPD service. AT&T largely
leveraged its twisted pair network using VDSL technology to deliver an IP-based TV service. AT&T has
also deployed an FTTP PON network to carry this IPTV service. Verizon deployed a PON fiber network
(FiOS) from the start, but chose to leverage cable technology to deliver its MVPD service to the point
that they also make use of CableCARD in their set-top boxes as well as in support of retail devices. To
accomplish this, Verizon used a separate wavelength to carry an RF spectrum with broadcast TV
channels. The two-way PON network is used to carry two-way services, including VoD. This is
sometimes referred to as a Hybrid QAM/IP implementation, as QAM is used to carry the broadcast
channels and IP is used to carry VoD services.
AT&T Technologies and Architectures [43]
In 2004 SBC/AT&T participated in the Microsoft IPTV Early Adopters Program (EAP). The IPTV
Mediaroom system was designed as an application platform to support the IPTV service and evolution of
service features. The platform is now owned and maintained by Ericsson. AT&T offers this service over
both copper (VDSL) and Fiber (FTTP) networks. The service is based on an all Internet Protocol (IP)
delivery for Linear/Live, and VOD. The system encompasses a number of proprietary features such as
Instant Channel Change (ICC), Multiview, and a large number of interactive applications, an EPG, search
engine, recommendations, integrated service features such a caller-ID on the TV, etc. Applications such
as Multiview are integrated within the Mediaroom software client. AT&T is a licensee of the Mediaroom
proprietary IPTV system and additional implementation details has to be obtained directly through
Ericsson. The Microsoft Mediaroom DRM is used for content protection on AT&T U-verse STBs with an
embedded secure SOC. U-verse is offered to third party devices such as smart phones (iOS, Android),
tablets, PCs and laptops through AT&T U-verse applications. PlayReady DRM is used for content
protection on these devices.
Figure 10 is a diagram of the AT&T U-verse Architecture. U-verse content is acquired and gathered at a
central location, the Super Hub Office (SHO), for national linear channels and VOD assets. Linear
content is encoded to AT&T’s unique specifications and distributed via multicast from the SHO to Video
Hub Offices (VHOs). The content is then multicast to the end user, when requested. Local channels are
acquired locally and encoded to AT&T’s unique specifications at the VHOs. VOD assets are encoded to
AT&T’s unique specifications and transported to the SHO
1
. From there they are distributed to the VHOs
via multicast, and stored locally at the VHOs. The assets are then streamed from the VHOs to the end
user via unicast, when requested.
Linear channels are encoded using H.264 video compression and Dolby Digital Plus (DD+) converted to
AC-3 by the STB or AAC audio, and contained within an MPEG-2 transport stream. When ingested into
Mediaroom, the channels are encrypted and encapsulated as RTP streams via the Acquisition Servers (A-
1
Note that AT&T does not use the CableLabs encoding specifications to encode content.
DSTAC WG4 Report
August 4, 2015
23
servers), and distributed via multicast to the local VHOs. Linear channels are also acquired by a
Distribution Server (D-server), which is at the VHO and used for instant channel change. When a user
switches to a live channel, a proprietary ICC enables a fast channel change implementation.
Figure 10 - AT&T U-verse Architecture
VOD assets are encoded using H.264 video and AC-3 audio, and contained within an MPEG-2 transport
stream. When ingested into Mediaroom, the assets are encrypted, encapsulated as an RTP stream, then
distributed and stored at the local VHOs on VOD Servers (V-servers). When initiated by the user, VOD
assets are streamed from the VHO V-servers to the user’s receiver over HTTP.
The U-verse Mediaroom DRM is used to enforce license restrictions from content agreements and
provides overall content protection. The DRM is based on 128-bit AES and 2048-bit RSA encryption.
Linear content is encrypted either at the SHO, or at the local VHO (for local channels). The encrypted
channels are distributed to the end user’s STB where they are decrypted using an embedded secure
SOC. VOD assets are encrypted at the SHO after being acquired from the content provider. The
encrypted assets are then distributed through the network and only decrypted once it is streamed to
the end user’s STB. Content outputs are also protected via HDCP, CGMS-A, and Macrovision. The output
controls are implemented through the client application.
AT&T U-verse is also available online at uverse.com, and on tablets and smart phones via the U-verse
mobile application. Uverse.com offers a web site where users can login and view services. Some
content flows through an internal process and other content is hosted directly through third parties like
Hulu, Turner, etc. Content is protected via PlayReady DRM. The U-verse mobile app for phones and
tablets are developed internally and content is encoded and hosted using a third party. Content is
protected via PlayReady DRM.
DSTAC WG4 Report
August 4, 2015
24
New updated U-verse Mediaroom software is pushed to U-verse STBs at least twice a year: offering new
features, improved performance, security and protocol system updates and updated user experience.
AT&T is planning to deploy 4K and HEVC, more advanced STBs to provide more value-added services to
U-verse customers. Access bandwidth is improving with the provisioning of more bandwidth over VDSL
and the deployment of more fiber (GigaPower). AT&T will be deploying more advanced Wi-Fi
technologies (i.e. 802.11ac) for both video and data distribution and expanding U-verse applications to
reach more and more third-party devices, and offering more interactive applications.
Verizon Technologies and Architectures [44]
Verizon took an alternate approach to AT&T by deploying a FTTP network known as FiOS. The Verizon
FiOS network is a Passive Optical Network (PON) either B-PON or G-PON with the addition of an
“overlay” wavelength (1550nm) to transmit broadcast video over RF. VOD is distributed over IP using
data/voice wavelengths (1490nm & 1310nm). Figure 11 shows the Optical Spectrum on the PON
network based on ITU G.98x PON standards. Figure 12 provides a diagram of the FiOS access network
showing the B/G-PON OLT for two-way voice, data, and VoD traffic, the Erbium Doped Fiber Amplifier
(EDFA) used to inject the broadcast RF on the fiber, and the ONT at the customer premise. This diagram
also shows the optical wavelengths used for the FiOS service. This architecture provides full support for
both cable style RF video as well as emerging IPTV video technologies. Moving the VOD traffic to the
B/G-PON IP network freed up RF spectrum for broadcast HDTV growth and provides greater scale as
demand for voice, data, and VoD increases. The network protocols used on the B/G-PON network are
ATM AAL1&2 for Plain Old Telephone Service (POTS) and ATM AAL5 for Broadband Internet and VoD.
Figure 11 - ITU G.98x PON Optical Spectrum
DSTAC WG4 Report
August 4, 2015
25
Figure 12 - Verizon FiOS Access Network
Figure 13 shows the high-level Verizon architecture. Content is received at two Super Head Ends (SHE)
for purposes of redundancy. A Long Haul Network (LHN) is used for the National Video Distribution
Network to carry the video traffic from a SHE to multiple Video Hub Offices (VHO), each of which serves
a major metropolitan or franchise area. The Metro Video Distribution Network distributes the video
traffic from a VHO to multiple Video Serving Offices (VSO) where it is then distributed over the PON
access network to the customer premise. This diagram also shows which network protocols used at
which points in the overall architecture.
Figure 14 shows the FiOS Hybrid QAM/IP set-top box and dual networks over which it connects to the
VSO. First, there is the one-way overlay interface that carries broadcast video using 256 QAM and
MPEG-2 Transport Streams (TS). In addition, there are two OOB downstream channels to support
multiple encryption systems: SCTE-55-1 for the MediaCipher CAS system and SCTE-55-2 for the
PowerKey CAS system, similar to that used by most US Cable operators after fiber termination. These
OOB channels carry System Information (SI), Entitlement Management Messages (EMM) and other
control plane signaling for box control and configuration. The IP Interface carries VOD content,
duplicates some of the OOB signaling and carries additional application data including widgets, guide
data, and gaming traffic.
DSTAC WG4 Report
August 4, 2015
26
Figure 13 - Verizon FiOS High-Level Architecture
Figure 14- Verizon FiOS Dual-Network Hybrid STB Architecture
DSTAC WG4 Report
August 4, 2015
27
The Verizon FiOS system uses both MediaCipher and PowerKey CAS systems in all markets via a
Simulcrypt compliant architecture. All channels and VOD are encrypted using the DVB Common
Scrambling Algorithm (CSA) cipher. The system also fully supports the CableCARD interface with
different CableCARDs provided for MediaCipher and PowerKey. To support CableCARD it was necessary
to support the distribution of required Uni-Directional Cable Service information such as System
Information and EMMs via the RF OOB channel. However for non-uni-directional services the IP
network is used instead. See WG2 report section III D [45]. In order to support simulcrypt, the FiOS
headends comply with the DVB Simulcrypt standard. In the FiOS simulcrypt implementation, the
MediaCipher CAS has the sole Code Word Generator (CWG) function. Simulcrypt also increased the
complexity of the system. Both the Mediacipher and PowerKey CAS systems are accessing the same
commonly encrypted version of the content. In addition, many other channels and VoD content are
available through alternate IP communications channels.
Verizon supports retail devices such as Smart Phones, Tablets, Smart-TVs, and Gaming Platforms. Non-
FiOS access networks make use of DRM rather than CAS for content protection. The DRM solutions are
based on 128 bit AES CBC cipher.
Direct-to-Home (DTH) Satellite Dish (small dish)
For customers in northern Alaska, the DBS satellite geometry coupled with the usual 1m dish does not
provide enough signal strength for reliable operation. They will use larger dishes. Further, although the
service delivered to customers in Alaska and Hawaii is comparable to the service delivered to the
continental 48 states, the specific transponders and orbital locations used for delivery are likely to be
different.
Over-the-Air Network Antenna Tuners (ATSC)
DBS receivers will commonly include ATSC tuners for local channel reception. The receiver integrates
any off-air channels with DBS-carried HD and SD versions of the same.
Home Network Technologies
Home Networking Overview
AT&T U-verse supports both wired and wireless home networking for video distribution. In homes with
structured wiring/Ethernet cable wiring (i.e. CAT-5 wiring), the Residential Gateway (RG) and STBs are
connected using the available structured wiring. If structured wiring is not available, AT&T is using HPNA
over coax for wired video distribution. AT&T is also offering a Wireless STBs (WSTBs) and a dedicated
Wireless Access Point (WAP) using the 802.11n Wi-Fi technology for video distribution. Figure 15 shows
an example of home networking diagram.
DSTAC WG4 Report
August 4, 2015
28
Figure 15 - Example Home Network
Typically, VDSL is terminated at the RG using a coaxial cable or a twisted pair copper cable. Content is
distributed to wired STBs via either HPNA over coax, or standard Ethernet cables, or wireless networks.
In terms of Access network technology, AT&T is offering broadband services over both copper and fiber
to the home networks. For the U-verse copper-based customers, AT&T is using VDSL speeds of up to
100Mbps and for fiber-based customers, AT&T is offering broadband speeds of up to 1Gbps.
Wireless Network Connectivity
Over the last decade wireless performance has improved exponentially as a result of technologies and
features such as Multiple Input Multiple Output (MIMO), Transmit Beamforming (TxBF) and availability
of additional spectrum. A number of wireless vendors are working on optimizing Wi-Fi silicon for in-
home high definition video streaming. Figure 16 shows some of the current in home wireless
technologies.
Figure 16 - Current in Home Wireless Technologies
Both 802.11ac and 802.11n claim enough capacity to support in-home video streaming. Many Wi-Fi
products, including 802.11n, support Multiple Input Multiple Output (MIMO), digital Beamforming and
operations in 5GHz spectrum. These technologies promise greater reliability and even better
DSTAC WG4 Report
August 4, 2015
29
performance than legacy Wi-Fi technologies. These technologies are application agnostic and allow
operators to use device and service discovery technologies defined in DLNA.
Tunnel Direct Link Setup (TDLS) and Wi-Fi Direct are efficient methods for video streaming between two
Wi-Fi clients. MSOs should consider these technologies for in-home video streaming if the cable video
source (e.g. cable video gateway) in the home can be configured as a Wi-Fi client. The service discovery
methods defined in Digital Life Living Alliance (DLNA) can be used while the TDLS clients are connected
through an AP. A new Wi-Fi Direct Application Service Platform (ASP) to advertise and discover cable
video services is required before Wi-Fi Direct can be used for in-home cable video streaming.
Miracast uses TDLS or Wi-Fi Direct as underlying transport. Unlike TDLS and Wi-Fi Direct, Miracast also
defines application specific procedures such as content security methods and media streaming protocols
to support screen mirroring and video streaming between two Wi-Fi clients. Miracast currently does not
require support for High Definition video streaming using MPEG-2.
Use of Wi-Fi for in-home video streaming introduces a number of factors that influence the design of
home network architecture. Some of these factors are:
• Does the customer subscribe to both video and Internet services from the same of different
service provider?
• Is the video source (e.g. video gateway) connected to the home network LAN using wired or
wireless network?
• Are there separate IP networks in the home for video and data services? An architecture using
separate Wireless LAN for video and data can result in confusion for the customer since a device
connected to the Wi-Fi AP for video services will not be able to access data services without first
disconnecting from the video Wi-Fi network, and then connecting to the data Wi-Fi network.
WiGig (802.11ad) supports data rate up to 7 Gbps using 60 GHz frequency band. The indoor
coverage range for WiGig is about 10 meters, which is good for communication between two
devices in the same or next room.
802.11ac versus 802.11n
802.11ac delivers higher throughput than 802.11n, as a result of the support for 80 MHz channels and
256 QAM. This advantage is more obvious when Wi-Fi clients are at close range to the Wi-Fi AP. The
throughput performance of the two technologies is comparable at long range (e.g., < -70 dBm RSSI).
While either 802.11n or 802.11ac can be used for video streaming, 802.11ac is the current generation
Wi-Fi technology, and it supports some features that were not part of the 802.11n standard. Table 2
below provides a highlight of some of the differences between 802.11n and 802.11ac.
Features
802.11n
802.11ac
Frequency Band
2.4 or 5 GHz
5 GHz only
Channel Bandwidth
20, 40 MHz
20, 40, 80, 160, 80+80 MHz
Modulation & Coding
64 QAM
256 QAM
DSTAC WG4 Report
August 4, 2015
30
Features
802.11n
802.11ac
Scheme
Spatial Streams
Up to 4
Up to 8
Transmit Beamforming
Optional
Standardized
Max Throughput
600 Mbps
3.2 Gbps
MU-MIMO
No
Yes
Availability
Available for some time now
First generation available now
Table 2 - Comparison 802.11n and 802.11ac features
In addition to the features in Table 2, 802.11ac also includes support for features such as Dynamic
Bandwidth Management, which can be very handy in mitigating interference and improving spectral
efficiency. This feature allows an AP to dynamically choose channel bandwidth to each client on a frame-
to-frame basis.
The first generation 802.11ac products support only 20, 40 and 80 MHz channel bandwidth. The current
FCC spectrum rules do not allow for a 160 MHz channel. Channel bandwidth of 80 MHz+80 MHz and 160
MHz are expected in the second-generation 802.11ac products. Support for MU-MIMO and Dynamic
Bandwidth Management are also expected in the second-generation 802.11ac products.
AT&T is deploying a dedicated video Wireless AP (WAP) that is based on 4x4 802.11n. The video WAP is
strictly used for video distribution to wireless standalone STBs that are based on 802.11n Wi-Fi standard.
TUNNEL DIRECT LINK SETUP (TDLS)
TDLS allows network-connected client devices to create a secure, direct link to transfer data more
efficiently. The client devices first establish a control channel between them through the AP. The control
channel is then used to negotiate parameters (e.g., channel) for the direct link. APs are not required to
support any new functionality for two TDLS compliant devices to negotiate a direct link.
TDLS offers multiple benefits, including efficient data transmission between client devices by removing
the AP from the communication link. Use of direct communication channel also allows the client to
negotiate capabilities independent of the AP. For example, clients can choose a wider channel, efficient
modulation scheme, security and channel that are more suitable for direct link between the client
devices.
TDLS devices, communicating with each other over a direct link, are also allowed to maintain full access
to the Wi-Fi network simultaneously, which for example, allows the client device to stream video to
another device in the home over the direct link; and at the same time allow user to surf Internet via
connectivity to the AP. If the TDLS direct link is switched to another channel, the stations periodically
switch back to the home channel to maintain connectivity with the Wi-Fi network.
The WFA has certified multiple products for TDLS, including Broadcom and Marvel. TDLS is based on
IEEE 802.11z, and is one of the optional features of Miracast (Wi-Fi Display).
DSTAC WG4 Report
August 4, 2015
31
WI-FI DIRECT
Wi-Fi Direct allows Wi-Fi client devices to connect directly without use of an AP. Unlike TDLS, Wi-Fi client
devices are not required to be connected to an AP to establish a Wi-Fi Direct link. Wi-Fi Direct also
includes support for device and service discovery. Wi-Fi Direct devices can establish a one-to-one
connection, or a group of several Wi-Fi Direct devices can connect simultaneously.
Wi-Fi Direct offers multiple benefits, including ease of use and immediate utility and enables
applications such as printing by establishing a peer to peer connection between the Wi-Fi Direct enabled
printer and client device, content sharing between two Wi-Fi Direct enabled devices, and displaying
content from one Wi-Fi Direct device to another without requiring any Wi-Fi network infrastructure.
Wi-Fi Direct certifies products, which implement technology defined in the WFA Peer-to-Peer Technical
Specification. The WFA has certified multiple products for Wi-Fi Direct. As of 2012, there are over 1100
Wi-Fi Direct certified products.
Wi-Fi Direct is the core transport mechanism for Miracast (Wi-Fi Display).
MIRACAST
Miracast provides seamless display of content between devices using Wi-Fi Direct as the transport
mechanism. Miracast also includes optional support TDLS as a transport mechanism.
The key features supported in Miracast include device and service discovery, connection establishment
and management, security and content protection, and content transmission optimization. Similar to
Wi-Fi Direct and TDLS, Miracast is client functionality and does not require updates to AP devices.
Primary use cases for Miracast are screen mirroring and video streaming.
Miracast certifies products, which implement technology defined in the Wi-Fi Display Technical
Specification. As of this writing many devices (e.g., Smart phones) have been certified for Miracast.
WIRELESS GIGABIT (WIGIG)
WiGig was originally developed in WiGig Alliance. In 2013, WiGig Alliance and Wi-Fi Alliance united,
consolidating WiGig technology and certification development in Wi-Fi Alliance. The WiGig technology
offers short-range multi-gigabit connections for wide variety of applications including video, audio and
data. The following is a list of applications that WFA is focusing on:
• WiGig Display Extension
• WiGig Serial Extension
• WiGig Bus Extension
• WiGig SD Extension
The WiGig technology is the basis of IEEE 802.11ad amendment and supports Beamforming and data
rates up to 7 Gbps in 60 GHz frequency band. Many WiGig products are also expected to support Wi-Fi,
along with mechanisms for smooth handovers from 60 GHz to 2.4 GHz and 5 GHz band. The indoor
coverage range is about 10 meters, which is adequate for communication between two devices in the
same or next room. A number of vendors, including Atheros, Marvell and Broadcom, Dell, Intel,
DSTAC WG4 Report
August 4, 2015
32
Panasonic and Samsung are working with the WFA in the development of technology and certification
testing program. The WFA currently expects to launch WiGig certification program in 2016.
Ethernet Network Connectivity
Some MVPD provided STB also have wired Ethernet connectivity. All U-verse STBs are equipped with a
Fast Ethernet connector enabling the 10/100-base fast Ethernet home networking. This enables
consumers with Ethernet wired homes to directly connect the STBs to the network termination units or
RGs inside the home without the need for extensive rewiring or setup of high-fidelity wireless networks.
Bluetooth
Increasingly Bluetooth networking is being utilized by many CE devices and applications to extend their
functionality to support new features and capabilities. These include (among others) remote controls,
game controllers, and audio streamers.
ZigBee® RF4CE Remote Control Specification
Traditionally, remote controls for set-top boxes and CE devices have made use of InfraRed (IR) protocols
that have relied on line of sight between the remote control and the device itself. Increasingly, these
devices have been installed in entertainment centers or equipment closets that preclude line of sight
use by IR remote controls. As a result the use of RF protocols like ZigBee RF4CE are being used in
remote controls for set-top boxes. The cable industry has adopted a profile of RF4CE that is published
by CableLabs
2
.
HPNA Network Connectivity
AT&T is using the HPNA V3 over Coax that is based on the ITU G.9954-2006 standard. HPNA operates in
the 12-44 MHz frequency band and offers a data throughput of up to 320 Mbps. The HPNA technology
also supports Quality of Service (QoS), Differentiated Services Code Point (DSCP) with 8 priority queues.
The technology also supports dynamic bandwidth allocation and coexists with VDSL.
MoCA 2.0 Technology Overview
Used for whole-home DVR, IP networking (IPVOD, CAS call-home for PPV/VOD purchase reporting,
diagnostics, application data, diagnostics), software download and client control
Please refer to http://www.mocalliance.org/ for more information.
A typical in-home coaxial cable architecture consists of a tree-and-branch network topology using RF
splitters and coaxial RG-6 or RG-59 cables. The multimedia signal enters the home via an Optical
Network Unit (ONU) or via Cable gateway, Digital Subscriber Line (DSL) gateway, or via a satellite dish.
Multimedia content is distributed to each room in the home using the in-home coaxial network. The
home must support multiple simultaneous HDTV, SDTV, audio, data, voice-over IP, gaming, and other
multimedia usages both from the broadcast network and from the in-home DVR or storage devices.
Each wired room and device may be either, or both, a source or sink of multimedia content both to and
2
Cable Profile for the ZigBee® RF4CE Remote Control Specification, OC-SP-RF4CE-I01-120924, September 24,
2012.
DSTAC WG4 Report
August 4, 2015
33
from multiple simultaneous entertainment devices in the home. Although the in-home coax is a
relatively static channel, the presence of coaxial splitters creates a highly dispersive multipath channel
that can cause significant echoes in addition to high signal attenuation when communicating between
various networking devices.
The in-home coaxial network connectivity must provide a reliable room-to-room, peer-to-peer, full-
mesh connectivity among all sources and sinks in the home. In order to support at least three
simultaneous HDTV and SDTV multimedia streams, the in-home network is required to have at least 60
Mb/s, and in many cases greater than 100 Mb/s data throughput with low packet error rate and low
average latency. These network performance requirements, adopted by MoCA, must be satisfied when
other services are added or when a neighbor or a family member runs services in the home.
The initial MoCA technology using the existing in-home coaxial cables was based on the MoCA 1.1
standard ratified in 2007. It uses bit-loaded Orthogonal Frequency Division Multiplexing (OFDM)
modulation with 224 subcarriers in a 50 MHz channel. Bit-loaded OFDM was selected for MoCA because
it is robust against static or slowly changing multipath and optimizes the modulation between every pair
of devices. When bit loading, each MoCA device probes the channel between itself and every other
MoCA device in the network and selects the modulation on each of the 224 subcarriers based on the
probe results: the better the signal-to-noise ratio (SNR) on a subcarrier, the higher the modulation
assigned to that subcarrier. MoCA 1.1 uses a maximum subcarrier modulation of 256 QAM. Since the
MoCA PHY layer adapts each link between node pairs independently, the channel capacity can be
different between different nodes, as well as between the forward and reverse directions of the same
node. The bit-loading parameters for a particular path are called a PHY profile. It enables a maximum
PHY rate of 275 Mbps, and network throughput rate of 175 Mbps at low Packet Error Rate (PER ≤ 10
-5
)
and low average one-way latency (≤ 3.5 milliseconds) in defined frequency bands from 475 MHz to 1550
MHz. The latest MoCA 2.0 standard, which was ratified in June 2010, includes the following key features:
● Increased channel bandwidth from 50 MHz to 100 MHz (225 MHz) for bonded channels with increased
maximum modulation density from 256-QAM to 1024-QAM
● Forward-Error-Correction (FEC) was changed from Reed-Solomon (RS) to Quasi-Cyclic (QC)-LDPC
● Expanded MoCA channel plan from 400 MHz to 1675 MHz in defined frequency bands to support bonded
channels operation, and two simultaneous independent networks
● Total MAC network throughput of 430 Mbps, and 860 Mbps with a bonded-channel in a 16-node network
● Full backward interoperability with MoCA 1.1 devices
● Turbo-mode for two-node network with network throughput > 1 Gbps
● Using Orthogonal Frequency Division Multiple Access (OFDMA) for Reservation Requests (RRs) from each
MoCA device to the NC
● Four new power states (‘Active’, ‘Idle’, ‘Standby’, ‘Sleep’) for energy savings were defined
● New multicast Parameterized QoS (PQoS) flows with reduced one-way average latency
● Enhanced link privacy using Advanced Encryption Standard (AES) in Cipher-Block Chaining (CBC) mode
using 128-bit AES key length
Table 3 summarizes the MoCA 2.0 PHY and Medium Access Control (MAC) layer key parameters.
DSTAC WG4 Report
August 4, 2015
34
PARAMETER NAME
PARAMETER VALUE
NOTES
Bandwidth
100 MHz, 225 MHz (bonded channels)
Modulation Type
OFDM
Modulation Density
BPSK up to 1024-QAM
Subcarrier Spacing
195.3125 kHz
Cyclic Prefix
0.2 to 1.28 µs
In increments of 0.2 µs for
data
FEC
QC-LDPC with code rate 39/46
LDPC = Low-Density Parity
Code
Maximum PHY Rate
(theoretical)
733 Mbps, 1466 Mbps (bonded
channels)
Maximum MAC Rate
430 Mbps, 860 Mbps (w/bonded
channel)
Medium Access Control
(MAC)
TDD Scheduled MAC with Tx
opportunities by NC
QoS
Contention-free service with low-
latency multicast flows
Network Management
SNMP MIBs for MoCA 1.1
TR-069 support for MoCA 1.1
Maximum Network Size
16 adapters
Power Save
‘Active, ‘Idle’, ‘Standby’, and ‘Sleep’
modes
Security
128-bit AES encryption in CBC mode
Two sets of static and dynamic keys for
data encryption
CBC = Cipher Block Chaining
Table 3 - Summary of MoCA 2.0 PHY and MAC Layer Parameters
Figure 17- MoCA 2.0 Extended Band D Frequency Plan
DSTAC WG4 Report
August 4, 2015
35
MoCA 2.0 PHY layer operates in defined frequency bands from 400 MHz to 1675 MHz. Figure 17 shows
the MoCA 2.0 Extended band D (ExD) frequency plan, which is used by most of the Cable operators in
North America. Band D defined for MoCA 1.1 devices was extended from 1125 MHz to 1675 MHz,
introducing two D sub-bands (D-low and D-high) so that two independent MoCA 2.0 networks can be
supported. The MoCA 2.0 channels (100 MHz) are centered on a 25 MHz grid, and can be tuned in 25
MHz increments. Bonded channels (225 MHz) consist of 100 MHz primary and secondary channels
centered on the 25 MHz grid with a 25 MHz gap between them. The ExD frequency plan supports mix-
mode operation with MoCA 2.0 and MoCA 1.1 devices. Other frequency bands include Band E (400 MHz
to 700 MHz) and band F (650 MHz to 875 MHz) used primarily by the satellite operators.
In some use cases, when a higher MAC throughput is required, MoCA 2.0 added a turbo mode support
in a two-node network. In this network nodes may eliminate some MAC overhead in order to maximize
the MAC throughput. The MAC throughput in a turbo mode is required to be > 500 Mbps using a 100
MHz channel, and > 1 Gbps using bonded-channels.
The MAC layer uses Time-Division-Duplexing (TDD) scheme where all the nodes on the network transmit
on the same frequency, but at different time slots or transmit opportunities. All the transmit
opportunities are coordinated by a single node called the Network Coordinator (NC). The NC is
dynamically selected from all the nodes in the network based on which node has the best broadcast
bitloading capability. The NC broadcasts to all the nodes a Media Access Plan (MAP) message
approximately every 1ms, defining when each node can transmit in the upcoming time period called a
MAP cycle. Thus, the NC ensures that there is no contention for the allocated transmit opportunities.
During each MAP cycle, the MoCA nodes are given the opportunity to send RRs to the NC. The NC
responds to all the RRs it receives in the MAP cycle by granting time slots in the next MAP cycle to as
many transmissions it can. These transmission grants are sent in the next MAP message. Thus, the nodes
‘know’ when they should send and receive data during the upcoming MAP cycle. The MoCA 1.1 network
throughput is reduced as the MoCA network expands from two nodes to more nodes due to increased
overhead since the NC must schedule additional RRs, which reduces transmission time. This issue was
addressed by MoCA 2.0 using OFDMA, allowing eight nodes simultaneously to send their RRs to the NC
where each node is transmitting its RR on a different set of subcarriers. Not only does this reduce the
overhead for the RRs, but also it reduces latency by allowing a MoCA 2.0 NC to grant RR opportunities to
all the nodes every MAP cycle.
3
MoCA defines two methods to protect video traffic from other type of traffic on the in-home coaxial
network. In the first method, video is sent as prioritized traffic based on the VLAN tag. Thus, the MoCA
device will provide preference to video streams with high MoCA priority compared with low-priority or
untagged traffic. The second method is to send video streams using Parameterized Quality of Service
(PQoS). A traffic flow with specific Traffic Specification (TSPEC) parameters is configured based on link
metrics of the flow. Once the PQoS flow is admitted to the network, its bandwidth is guaranteed to be
transported across the network. MoCA 2.0 defines additional TSPEC parameters for greater flow control
such as maximum latency, classification rule, in-order packet delivery and retransmission.
Energy efficiency of consumer products, particularly Set-Top Boxes (STBs) and networking devices is an
important requirement. U.S. Federal government and the European Commission have initiatives to
regulate the maximum allowed energy consumption of STBs and networking devices.
4
To address this
3
A. Monk, R. Lee, and Y. Hebron, “The Multimedia over Coax Alliance,” Proceedings of the IEEE vol.101 (2013).
4
European Commission, ICT Codes of Conduct – Please see
DSTAC WG4 Report
August 4, 2015
36
issue, MoCA 2.0 defined four power states as shown in Table 4, allowing the MoCA node under the
control of its host processor to move in and out of low-power states in coordination with other MoCA
devices in the network. In addition, the MoCA 2.0 specifies the rules for transitioning the MoCA device
from active state to any other power states, and from the other power states back to the active state.
POWER MODE
POWER MODE NAME
DESCRIPTION
M0
Active
Normal operation of the MoCA interface; full power
consumption.
M1
Idle
MoCA interface is unable to transmit data traffic, but can receive
broadcast and unicast traffic; fast wake-up time.
M2
Standby
MoCA interface is unable to transmit data traffic, but can receive
broadcast traffic; slower wake-up time.
M3
Sleep
MoCA interface is disconnected from the network.
Table 4 - MoCA 2.0 Power Mode Names and Description
MoCA 1.1 uses 56-bit Data Encryption Standard (DES) encryption for data traffic. The privacy of MoCA
2.0 was upgraded to 128-bit Advanced Encryption Standard (AES) encryption in Cipher Block Chaining
mode. Two sets of static and dynamic keys are used for data encryption. In addition, each MoCA device
has a programmable password, which is used for distinguishing between MoCA networks either in the
same home or adjacent homes.
HomePlug AV and other powerline transmissions
Used for IP networking (IPVOD, CAS call-home for PPV/VOD purchase reporting, application data, and
diagnostics).
Please refer to http://www.homeplug.org/ for more information.
Section III: Technologies (Functional) that enable the reception of
MVPD or OTT service:
These are usage of devices technologies from above as applied to MVPD or OTT service reception.
Gateways and MVPD Provided Devices and Environments
Home Network Video and Internet Gateways (includes Residential Gateway)
Key components and features of the Residential Gateway (RG) are:
● xDSL Modem: terminates single-pair and/or bonded-pair copper connections. The modem
detects the appropriate xDSL profile automatically and connects customers to the correct VDSL
profile.
● Support for local network connectivity:
▪ Wired: Ethernet, HPNA, MoCA
http://re.jrc.ec.europa.eu/energyefficiency/html/standby_initiative_main.htm
DSTAC WG4 Report
August 4, 2015
37
▪ Wireless: 2.4GHz 802.11n, 5GHz 802.11ac
● Supports integrated VoIP
● TR-069 Compliant, Integrated Firewall, NAT/PAT support, Diagnostics support
● Supports Ad Insertion (Also see DBS section above)
o AT&T currently implements multiple levels of ad insertion into MediaRoom compliant
streams. This includes National, VHO, and Zoned insertion. Zoned ad insertion takes place on the
RG using a proprietary protocol and mechanism developed with RG vendors. Targeted ad
insertion (currently in development) will take place using in-home MediaRoom DVR and STBs –
again using proprietary protocols and mechanisms developed by the middleware vendor.
● Provides Battery backup for the VoIP service
● Provides broadband internet access
● May optionally support DVR capabilities
● Other key interfaces are:
o DSL Modem, Gigabit Ethernet WAN, HPNA V3.1 Coax port, up to 4 Gigabit Ethernet LAN
ports
o 5GHz, 802.11 ac, 4x4 MIMO Wi-Fi, 2.4GHz 802.11n MIMO Wi-Fi
o 2 VoIP lines
o USB host support
Standalone STBs
AT&T is offering standalone wired and wireless STBs to U-verse customers. The U-verse standalone STBs
are designed with a dedicated video System on Chip (SoC) with a secure core to support identification,
authentication, and provisioning of services as well as Digital Right Management security system that is
used for content security and protection. All of AT&T U-verse STBs are HD capable STBs and the U-verse
content is encoded using the H.264/AC3/DD+ compression standards. Some of the key components of
the standalone non-DVR U-verse STBs are:
● Dedicated DRAM
● Application Flash
● Boot ROM (or Secure Flash)
● 10/100 Ethernet Port bridged with HPNA – Internal Ethernet switch
● HPNA V3
● USB 2.0 port
● Composite, Component, S-Video, HDMI, Optical TOSLINK Audio outputs
● Infra-Red (IR) Remote Control
● Status LEDs
DSTAC WG4 Report
August 4, 2015
38
Digital Video Recorder
AT&T is offering a local Digital Video Recorder (DVR) STB with up to 1TB of HDD. Other features of the
DVR STB hardware are similar to the standalone non-DVR STBs. In conjunction with the Mediaroom
client software application, AT&T is using the DVR STB to offer Total Home DVR (THDVR) and Remote
Pause Buffer services. The THDVR service enables customers to record and playback multiple HD
channels (up to 6-record and 3 Playback) simultaneously. Customers can initiate recording sessions and
playback of recorded content from any STBs within the home. In addition, the Mediaroom software
along with the DVR STB, enables pausing of live TV as well as the use of trick modes on live streams from
any STBs within the home. These features are based on proprietary implementations of THDVR and
Remote Pause Buffer in the Mediaroom software that is licensed by AT&T. The DVR also supports the
storage of ad assets and serving of these assets to other STBs within the home. See DBS section for
information on DVR use in DBS systems.
Cloud or Network DVRs
MVPD’s offer a Network/Multi-Room Digital Video Recording (MR-DVR) platform. Cablevision’s system
uses the existing STB within the home with no HDD. Other features of the MR-DVR STB are similar to the
standalone DVR STBs without a pause buffer. This cloud service becomes a total Multi-Room Home DVR
solution. This service enables customers to record and playback multiple HD channels (up to 15-
recordings) simultaneously. Customers can initiate recording sessions and playback of recorded content
from any STBs within the home. These features are based on proprietary implementations of MR-DVR
based on VOD protocols. The MR-DVR system also supports the storage of ad assets and serving of these
assets to other STBs within the home.
Mediaroom Applications Software
The Mediaroom application software is a proprietary IPTV application software licensed by AT&T for the
U-verse service. The IPTV Mediaroom system was designed as an application platform to support the
IPTV services and evolution of service features. The platform is now owned and maintained by Ericsson.
The U-verse IPTV service is based on an all Internet Protocol (IP) delivery for Linear/Live and VOD. The
service also encompasses a large number proprietary features and value-added services such as Instant
Channel Change (ICC), Multiview, and a large number of interactive applications. The Microsoft
Mediaroom DRM is used for content protection on AT&T U-verse STBs with an embedded secure SOC.
U-verse is offered to third party devices such as smart phones (iOS, Android), tablets, PCs and laptops
through AT&T U-verse applications. PlayReady DRM is used for content protection on these devices. Key
implementation details of the AT&T U-verse IPTV features are confidential/proprietary.
Application on Retail Device
Apple iOS
Applications deployed to the Apple App Store for operation on iOS devices are written against an Apple-
provided iOS SDK. These applications may incorporate code written in any of a number of languages,
but Objective-C and HTML5 are historically the most common. Video applications in the iOS context are
modal, though this may be changing somewhat in iOS 9. This means that content-provider library
DSTAC WG4 Report
August 4, 2015
39
discovery, search, and browsing are typically executed in the user-interface context of the application.
Developer deployment of applications and application updates is generally managed via the Apple App
Store for everyday users. Applications are submitted to Apple for review and distribution.
Google Android
Android device applications may be delivered to a device by a number of means ranging from side-
loading (direct installation) to various application stores (e.g. Amazon appstore, Samsung Galaxy Apps,
etc.), the Google Play store being the most popular. In the case of the Google Play store, applications
are submitted to the store and made available at the discretion of the application developer. Google
may remove application availability if an application is found to be malicious or otherwise harmful.
Video applications distributed on the Google Play store may be modal and isolated, as with iOS
applications, but this is not the only mechanism for browsing integration. Instead, Android applications
may expose their video programming via software interfaces that allow for system-integrated browsing,
searching, discovery, and selection. Amazon’s Fire TV provides similar functionality for 3
rd
party
applications, allowing for integrated browsing, search, and discovery. Playback in both cases is handled
by the 3
rd
party’s application, but this integration between the 1
st
party browsing UI and 3
rd
party video
playback UI does not require any service-specific user action. “Android TV” branded devices incorporate
a local federated search mechanism whereby catalog search queries can optionally satisfied by included
and downloaded applications. This mechanism allows applications to provide search “plug-ins” to give
unified search results to users on these devices.
Smart TV
With a number of available Smart TV platforms (e.g. Android TV, WebOS, Tizen, Yahoo! Connected TV,
Google TV, Google Cast), the approaches for application distribution and content discovery and playback
are varied. Approaches to distribution and display range from generally open to curated to closed.
Generally open systems (e.g. Android TV) provide APIs and distribution mechanisms that allow for
distribution control but remain largely unrestricted by their platform vendors, resorting to application
restriction, for example, in cases of user harm.
More curated Smart TV platforms (e.g. LG’s WebOS) provide APIs and distribution mechanisms but
require platform vendor approval (typically after extensive testing and validation) before an application
may be made available for use.
Further restriction is possible, leaving platform APIs and distribution mechanisms restricted by explicit
agreement between platform and service vendors. At present, this group is not aware of any Smart TV
platforms still using this approach to application distribution.
HTML5 with EME
HTML5 with EME encompasses a wide range of use cases for content discovery, search, navigation, and
playback, as HTML5 with EME is merely a technology stack allowing for host-based provisioning
DSTAC WG4 Report
August 4, 2015
40
negotiation. Though HTML5 “applications” may be delivered in a number of ways, the most common
approach is to receive the code and content in a browser context while interacting with a server.
PC-based ”Native” applications
Personal computer-based streaming applications from individual service providers are more rare. Some,
like Kodi and Boxee exist, but these are 3
rd
party aggregation applications often built without direct
input from service providers. SlingTV supports a PC/Mac client, and PC/Mac clients exist for MVPDs and
retail devices using SlingBox technology for streaming. As such, service support is inconsistent. We can
look to music navigation applications (e.g. WinAmp, iTunes, Songbird, Amazon MP3) as a possible design
example, but there are many distinct differences, including local library collection, high title count, and
short title (track) duration. Instead, video services are more commonly deployed to computers via
HTML with either EME or embedded plug-in viewing mechanisms (e.g. Flash, Silverlight).
Standalone Retail Devices
HDTV
What can be called an HDTV ranges in function from a dumb monitor to a display-integrated computer.
HDTV devices generally incorporate external digital, analog, and tuner inputs, and HDTV endpoint
devices may incorporate other interfaces such as USB, TOSLINK (for audio), CableCARD (on legacy
HDTVs), Ethernet, WiFi, etc. Generally, HDTV devices may receive MVPD content via tuning
unencrypted channels (e.g. ClearQAM, however not all cable providers have ClearQAM channels).
“Smart TV” HDTV devices may also access video content over WiFi, Ethernet, or local storage
connections.
DVR
Retail DVR devices vary greatly in functional characteristics and feature-sets, but a common feature
among these devices is the inclusion of the ability to record programming programmatically, typically,
but not necessarily, without the use of removable linear media such as videocassette or DVD+/-R. DVR
systems leverage hard disk drive (HDD) and/or other local storage devices to record and retain video
programs. Retail devices may be bound by regulation (e.g. Copy Control Information) with regards to
this fundamental behavior. Additionally, DVR devices may include “trick play” functionality such as
pause of live TV and may integrate other functionality (e.g. Netflix on TiVo devices). Furthermore, DVR
functionality may be included as a functional feature in other devices (e.g. Microsoft Windows Media
Center).
Portable media storage
Portable media storage devices (e.g. SD Cards, external Hard Disk Drives) may be used to store video
content for later playback. These devices can be connected via a number of interfaces, the most
common being USB. Content stored on these devices may be cryptographically “keyed” to be decodable
on a single device or limited group of devices.
DSTAC WG4 Report
August 4, 2015
41
Section IV: Technologies that enable the reception of MVPD or OTT
service:
This section provides information about specific technologies that enable the reception of MVPD or OTT
service.
Google Fiber IPTV System Overview
Summary
This outlines the various components of the Google Fiber IPTV service. It’s purpose is to explain how we
may operate differently than other MVPDs and also to explain how it’s service could be adapted to work
with a market for 3rd party retail navigation devices. Overall, Google Fiber operates like most MVPDs do
with regards to having installers, CSRs, headends, content ingestion/transcoding/distribution and in
home STBs.
Linear TV Feeds
Linear TV channels are sent out over IPTV multicast (UDP multicast). The channels use H264 video
encoding and either MPEG or Dolby Digital audio encoding. The transport layer is a single program
MPEG2 Transport Stream. They carry multiple audio tracks when present. Closed captioning and AFD
information is also retained in these streams. Retransmitted local broadcast channels are sent without
encryption. All other channels are encrypted using Widevine with EMM/ECM data present in the stream.
Households that do not subscribe to the TV service have the IPTV multicast signal blocked at the
network level.
Video on Demand
Google Fiber has all types of VOD content; free, subscription based and transactional. VOD content is
served over HTTP and encrypted using Widevine. The streaming format is specific to the Widevine VOD
implementation that is used. We also provide VOD content served over the DASH protocol [40]; which is
currently utilized by our mobile/tablet clients and will likely transition to this protocol for all VOD
streaming in the near future. VOD streamed via DASH supports playback using standard EME.
Metadata
Metadata relating to the program guide information and VOD content is delivered via HTTP to the
clients. This data also contains the mappings of logical TV channels to their actual multicast IP:port. It
comes down as a compressed BLOB of data which is a delta of the information from the last retrieval. It
is also possible to download the full set of information, which is what occurs for a newly provisioned
STB. The data is in a proprietary format. Imagery associated with the metadata has URLs specified in the
metadata so those images can be retrieved for presentation in the user interface.
Content Authorization
A secure HTTP RPC service is provided for clients to retrieve information relating to content
authorization and subscribed channels. Connection to this service requires validation of security
certificates in a bi-directional manner (i.e. SSL where both client & server certificates are validated). This
service provides the information on what specific channel lineup the device should be using (so it can
then request the proper metadata). It also provides a list of all the devices in the home that our whole
home DVR storage box is allowed to communicate with. It also lists all of the channels that the user is
authorized for viewing. The DRM components in the client also connect to this same service in order to
obtain the data they need in order to enable decryption of the subscribed linear TV channels and
DSTAC WG4 Report
August 4, 2015
42
authorized/purchased VOD content and know the output protection rules associated with that content.
(NOTE: These are not the actual encryption keys, but keys that in conjunction with the DRM secrets
loaded into the device along with the ECM/EMM information in the MPEG stream allows it to generate
the decryption keys for the content. Keys are rotated on a regular basis for the linear TV channels.)
Emergency Alert
EAS information is sent out over an IPTV multicast feed and contains all the information the device
would need in order to properly respond to an EAS/EAN event.
Monitoring & Logging
Device logs are uploaded regularly to Google servers for analysis and processing. We use the TR-069
protocol for management, provisioning, remote configuration and other types of data collection.
Slingbox
The Slingbox is a TV placeshifting device that allows users to watch their live TV or DVR content
anywhere via an IP connection. It is able to connect to virtually any MVPD’s STB. Connections are only
1-1, meaning a single session per Slingbox.
Please refer to http://www.slingbox.com/ for more information.
Mediaroom
In order for a third party to implement the Mediaroom features, they need to license the Mediaroom
platform. The following provides a high level overview of the two key features:
ICC: instant channel change is achieved by a combination of TCP and UDP IP traffic for a specific channel
and detailed implementation of ICC is confidential.
RUDP: Resilient UDP is another technology used by Microsoft to provide reliability. This is also a
proprietary Microsoft technology.
Section V: OTT Services
Some OTT services have different applications on different platforms. Table 5 describes the operation of
each application for the discovery and reception of content on a sample set of OTT services. This table is
not intended to be comprehensive or a survey of all current OTT services.
Discovery
Reception
Content
Type
Content source
Business
model(s)
Ad support
Amazon
In-app and
platform
search and
browse
Streaming
and
Download
Long Form TV
and Film
3rd party (studio)
and 1st party
Rent, Sale,
and
subscription
Content
promo only
Netflix
In-app and
platform
search and
browse
Streaming
Long Form TV
and Film
3rd party (studio)
and 1st party
Subscription
No
DSTAC WG4 Report
August 4, 2015
43
Hulu
In-app and
platform
search and
browse
Streaming
Long Form TV
and Film
3rd party (studio),
regional exclusive,
and 1st party
Ad-supported
(always) and
subscription
Yes
YouTube
In-app and
platform
search and
browse
Streaming
Originally
Short Form,
now
unlimited
Largely 3rd party
sourced (user
submission) with
some 1st party
content
Ad supported
and (pending)
subscription
Yes
SlingTV
In-app and
platform
search and
browse
Streaming
Live
Programming
Broadcaster/channel
Subscription
with optional
add-ons,
VOD, and C3
(subscription
inclusive)
In-band with
live content
Table 5 - Sample OTT Service ca. Summer 2015
Section VI: Essential Customer Experiences
Include messaging and protocols that enable these experiences during analysis.
PURPOSE
Through a series of Use Cases, specify the content subscription service elements that are currently
available and used by the market.
INTRODUCTION
These Use Cases serve to identify and describe the current service features that an end-subscriber
(consumer) may gain access to when they have a subscription to a content service.
Examples of a content subscription service would be a subscription to a Multichannel Video
Programming Distributor (MVPD) or an Over-The-Top (OTT) service. The dissemination of these services
can be transmitted through a series of paths, such as cable, satellite or via an Internet connection or a
combination thereof.
It is important to note that these subscriptions are governed by agreements made among several
parties. Users traditionally enter into agreements with the content subscription service. Content
subscription service providers typically enter into multiple agreements, including with content providers,
advertisers, metadata providers, CAS and DRM vendors, OEM set-top box manufacturers, and
others. Third party manufacturers currently enter into, and are bound by, specific licenses (such as
DFAST) and/or specific business arrangements, and regulatory and legal requirements.
This group of agreements governs the content ecosystem that is currently accessed by the
subscriber. The following Uses Cases take into account these agreements.
Outlining and categorizing virtually every service feature available aids in the identification of the salient
differences amongst the categories and service offerings. Some of the devices reviewed by the DSTAC
Working Group support only some use cases or only some features within a use case. The report
DSTAC WG4 Report
August 4, 2015
44
analyzes the features and use cases that are or should be supported. That analysis may assist in
evaluating alternative systems and features that are or should be baseline requirements for service
providers and device manufactures, as well as the evaluation of platforms or devices in the marketplace
that are able to satisfy these Use Cases.
It should also be noted that these Uses Cases may change over time. The purpose of this document is to
relay Use Cases based on current market availability.
END-USER Precondition:
In each of these use cases, the consumer already has a subscription with an MVPD or OTT provider.
USE CASE #1 - Tuning and Viewing a Linear Channel
USE CASE DESCRIPTION
This use case covers when a subscriber tunes to a new channel using channel up/down, direct channel
entry, or from other navigation (the linear and on-demand navigation use case is covered below).
TRANSMISSION METHODS
While an MVPD device must only support the transmission methods for the MVPD’s network, a retail
device for this use case should be able to support methods for transmission of linear channels, including:
TRANSMISSION METHOD
ACTIVE EXAMPLE
Analog
There are a small amount of Cable operators
in the country who still transmit some
channels using analog transmission methods.
QAM broadcast
Quadrature Amplitude Modulation (QAM) is
the standard for broadcast of digital video on
cable networks today. In the United States,
the QAM standard used is ANSI/SCTE 07,
2000: Digital Video Transmission Standard for
Cable Television.
QPSK DVB-S
Quadra-phase Shift Keying (QPSK) is a
modulation system used in DNBS broadcast
systems. DVB-S is an advanced coding system
defined by DVB.
QPSK DSS broadcast
See International Telecommunications Union,
Recommendation ITU-R BO.1516, 2001,
"Digital multiprogramme television systems
for use by satellite operating in the 11/12
GHz frequency range, System B"
DSTAC WG4 Report
August 4, 2015
45
TRANSMISSION METHOD
ACTIVE EXAMPLE
DVB-S2 broadcast
DVB-S2 is an advanced coding system defined
by DVB. See “Digital Video Broadcasting
(DVB) User guidelines for the second
generation system for Broadcasting,
Interactive Services, News Gathering and
other broadband satellite applications (DVB-
S2), ETSI TR 102 376, V1.1.1, February 2005.”
QPSK and 8-PSK Turbo broadcast
8-way-phase Shift keying 8-PSK
Multicast User Datagram Protocol (UDP)
See Google Fiber section for example.
Multicast Real-Time Protocol (RTP with
custom adaptation layer) over UDP
See AT&T section above for usage example.
Unicast RTP (with custom adaptation layer)
over UDP
The U-verse TV system uses unicast RTP
based messages to deliver instant channel
change video payload to the client. When
booted, each STB receives a listing of video
session assignments to a specific Distribution
server (D-Server) from the D-Server cluster.
The Payload is delivered vis Unicast RTP over
UDP by the D-Server. The RTP adaptation
fields contain information that identifies
various real-time events such as Blackout
markers and tables, Random Access Points
(RAP) among others. In addition to this, the
D-Server may add event specific markers to
the RTP extension for a specific request.
The unicast RTP delivery is also used for
delivering error correction payloads for lost
or corrupted packets as part of the resilient
UDP (RUDP) mechanism.
QAM switched digital video (SDV)
Switched Digital Video (SDV) for QAM
networks is a method of implementing IP
multicast using broadcast QAM transport
DSTAC WG4 Report
August 4, 2015
46
TRANSMISSION METHOD
ACTIVE EXAMPLE
rather than IP. This permits only those
broadcast channels in a service group that
are being watched to be transmitted to that
service group. Those channels which are not
being watched in a service group are not
transmitted and thus save bandwidth
enabling more channels to be carried in the
same amount of bandwidth as a purely
broadcast system. The two-way out-of-band
channel used on the particular system
provides the two-way communication path
necessary for a set-top to request a particular
SDV channel using a proprietary protocol.
NACK-Oriented Reliable Multicast (NORM)
Transport Protocol
NORM is an IETF RFC for a protocol that can
provide end-to-end reliable transport of
video streams over generic IP multicast
routing and forwarding services. CableLabs
recently issued several specifications that use
NORM for transport of Adaptive Bit-Rate
video streams over IP multicast. The relevant
specifications are:
● IP Multicast Server – Client Interface
Specification, OC-SP-MS-EMCI, Cable
Television Laboratories, Inc.
● IP Multicast Controller-Server Interface
Specification, OC-SP-MC-MSI, Cable
Television Laboratories, Inc.
● IP Multicast Controller-Client Interface
Specification, OC-SP-MC-EMCI, Cable
Television Laboratories, Inc.
IETF RFC 5740, NACK-Oriented Reliable
Multicast (NORM) Transport Protocol,
November 2009.
DSTAC WG4 Report
August 4, 2015
47
As some MVPDs transition to converged IP networks, new transmission methods will be introduced and
some transmission methods will be deprecated. Examples of IP streaming include HLS [38] and DASH
[40].
CODEC SUPPORT
While an MVPD device must only support the codecs used by the MVPD’s network, a retail device for
this use case should support audio and video codecs, including:
● MPEG-2 [6] (Note that DBS systems will typically use GOP structures lasting multiple seconds.)
● MPEG-4 AVC/H.264
● HEVC/H.265
● MPEG-1 Audio
● Dolby AC3
● Dolby Digital Plus
● AAC
● AAC Plus
The following table lists examples of codecs and how they are currently being used by the listed entities.
MVPD
Transport
Control Channel
Video Codec
Cable
QAM/MPEG-2 TS
QAM/MPEG-2 TS
QAM/MPEG-2 TS
QAM/MPEG-2 TS
QAM/MPEG-2 TS
QAM/MPEG-2 TS
SCTE-55-1
SCTE-55-1/DOCSIS
DOCSIS
SCTE-55-2/DOCSIS
In-Band
Generic IP
MPEG-2/AVC
MPEG-2/AVC
MPEG-2/AVC
MPEG-2/AVC
MPEG-2/AVC
MPEG-2/AVC
Satellite
QPSK/DSS TS, DVB-S2/MPEG-2 TS
(QPSK, DVB-S, 8-PSK Turbo)/MPEG-2 TS
In-Band
In-Band
MPEG-2/AVC
MPEG-2/AVC
Off-Air
8-VSB/MPEG-2 TS
N/A
Telco
Multicast/Unicast-IP/VDSL/FTTP
QAM/MPEG-2 TS & IP/BPON or IP/GPON
IP/VDSL/FTTP
SCTE-55-1/SCTE-
55-2
AVC
MPEG-2/AVC
Google
Fiber TV
IP/GPON/MPEG-2 TS
IP/GPON
AVC
Table 6 - Transport, Control, And Codec Support
NOTE: A earlier version of this table was cited within the DSTAC Working Group 2 report
Error! Reference source not found. (as “Table 1 Currently Deployed CAS Systems”) and
was described as a summary of known, deployed CAS systems, each of which has its
own unique licensing and trust infrastructure, along with the associated core ciphers,
transports, control channels, and video codecs in use.
As new video and audio codecs are introduced, MVPDs will take advantage of them. Over time some
codecs will be deprecated. In instances where a separate decoder is used these aforementioned codecs
may not be called upon for use. For example, a gateway device might not have an HDMI output, and
DSTAC WG4 Report
August 4, 2015
48
therefore have no decoders on board. The device with the decoder would be the end point client device,
such as a tablet or RUI client.
DSTAC WG4 Report
August 4, 2015
49
IMAGE QUALITY
While an MVPD device must only support the picture resolutions and formats used on the MVPD’s
network, a retail device for this use case should be capable of supporting common picture resolutions
and formats, including:
● SD 480i/480p
● HD 720p (30 and 60 fps)
● HD 1080i
● HD 1080p (24 and 30 fps)
● 4K and UltraHD (High Dynamic Range (HDR), Wide Color Gamut, deep pixel depth)
● 3D frame compatible (Side-by-side, Top-and-Bottom, Interlace)
As new picture resolutions and formats are introduced, MVPDs will take advantage of them. Over time
some resolutions and formats will be deprecated.
Because content may be decoded to various resolutions and refresh rates, devices displaying content to
different target resolutions and rates should be capable of spatially and temporally resampling supplied
content to maintain spatial and temporal consistency. Example algorithms include, but are not limited
to, nearest-neighbor, bilinear, Lanczos.
Normative References:
● ARIB STD-B56, “UHDTV System Parameters for Programme Production”
STREAM MANAGEMENT (Resource Allocation)
Stream management is the allocation of stream resources within a defined network. Where necessary, a
device for this use case must support the concurrent stream management required to limit the number
of concurrent streams that a subscriber can receive and/or view. Stream management is also used to
manage the number of simultaneous ingress and egress streams for THDVR.
The device shall limit streams to be consistent with the number of authorized access points. Note that
stream management is not limited to solely HD and SD streams.
Stream management is necessary when addressing access network bandwidth limitations, tuner
limitations (in particular in the case of satellite) or fraud prevention (credential or password sharing).
SYSTEM
ACTIVE EXAMPLE
AT&T U-Verse
Stream management used by Mediaroom is a proprietary implementation
that manages the number concurrent WAN streams (coming to the home)
and DVR record and playback streams. This feature is part of the
Mediaroom application software running on the STBs.
DBS
DBS receivers typically have limited numbers of tuners that are distributed
among DVR recordings, attached displays, and network displays.
DSTAC WG4 Report
August 4, 2015
50
SYSTEM
ACTIVE EXAMPLE
Management of tuner resources is a task for the main server in a DBS
installation.
CableCARD
CableCARD supports 6 concurrent programs with 120Mbit maximum
bandwidth.
Table 7 - Examples of Stream Management
SWITCHED DIGITAL VIDEO
Switched Digital Video (SDV) allows an MVPD to make efficient use of bandwidth by only broadcasting
those channels that are currently being watched within a given area, e.g., a node, or neighborhood. This
allows the MVDP to use the reclaimed bandwidth for other services, including higher data speeds. The
network looks for tell-tale signs of viewer inactivity, asks the viewer if he or she is still watching, and
recovers the channel if there is no response. The exact SDV techniques vary by vendor, but they rely
upon SDV client software in the customer device or a tuning adapter as well as two way communication.
For SDV to work within retail devices without the requirement of an external MVPD-specific tuning
adapter, all current implementations would need to be ported and a predictable software client would
need to be present in the retail device. These solutions would need to be tested for operability and for
functional tuning performance across MVPDs, and room would need to be left for the implementations
to continue to evolve and improve. If there is no client to communicate viewing status upstream, there
is no recovery of bandwidth, and SDV would fail in its essential purpose of opening bandwidth for more
channels, more high-definition, faster broadband and more advanced services. See below for high level
overview of SDV. External tuning adapters are used by some UDCPs to receive SDV.
Figure 18- Switched and Non Switched Video
Some of the key elements of SDV are:
DSTAC WG4 Report
August 4, 2015
51
● Dynamic channel mapping information identifying the current channels being transmitted into a
service group and their tuning information.
● Tuning requirements (methods).
● Keep-alive messages, indicating that a channel is still being watched.
● Time-outs, indicating that a channel may potentially no longer being viewed based on the lack of
viewer activity via the remote control.
● Customer notifications (e.g., tear-down of channel), to insure that the viewer is in fact no longer
watching the channel, before actually taking down the channel.
APPLICATIONS
Applications provide additional information or access to additional services, as selected by or subscribed
to, by the User. A device with the ability to support integrated or program synchronous applications,
should ensure that integrated applications or applications associated with the tuned channel, are
presented and accessible to the User. Currently, some technologies used are Widgets, Enhanced TV
(EBIF) [37], and MediaRoom. Other proprietary applications, such as those related to OTT services, may
also be supported by the device.
Examples of integrated or program synchronous applications include:
● Headlines ticker
● Instant local weather
● Sports scores and statistics
● Shop by remote
● Bookmarking ads
● Social networks (Twitter, IM, SMS, etc.)
● Mosaic channels
● Telescoping
● Auto-tune HD
● “Mix” channels (mosaic of multiple channels / camera angles)
● Set timers (e.g. for future sport events or tune to current events)
● Communication service compatibility
o Voicemail, CallerID requires integration with telephone networks
o May be used for home automation and home security networks
ADVERTISING
Advertising messaging, when part of a service, should not be deliberately filtered out. The following
advertising models must be supported:
● Local insertion of broadcast advertising into linear television
● Local insertion of zoned or targeted advertising into linear television
i) Must receive if delivered from network
ii) Must securely store & delete in device and insert if managed by the device
● Interactive Request For Information (RFI)
● Telescoping to on-demand advertising
● Must honor and be compliant with advertising rules, such as:
i) Rules about ads in conjunction with a network’s video
ii) Rules preventing interference, substitution or removal of ads
DSTAC WG4 Report
August 4, 2015
52
iii) Limitations on web links when programming is directed to children
iv) Rules about the inclusion of advertisements, promotions, sponsorships, and/or overlays that
are displayed, in or around, a network’s video window (linear & VOD) while the guide
experience is engaged.
v) Support for availability windows (e.g., C3 or Post-C3 ad loads)
● Ad measurement and reporting
i) Report back the display of an ad for frequency limits or analytics of reach of the ad
campaign
● Protection of ad boundaries, especially as it relates to substitute programming or downstream
devices
● Ad asset storage and lifecycle management
● Integration with Ad Decision Management (ADM) and Ad Decision Systems (ADS)
● Honor C+3, C+7, etc. ad insertion rules for DVR content playback
This use case also requires support for an audit trail to validate that the advertising has been presented
as relayed.
DEVICE REQUIREMENTS
1) A device must ensure that blackouts are supported.
a. Content delivered to the device (e.g., from satellite or cable distribution hub or IPTV
super hub office) must be blacked out if not authorized (e.g., in-home vs. out-of-
home, in-market vs. out-of-market, in-region vs. out-of-region, domestic vs.
international).
b. Customer notifications, including messaging, signaling & placement (e.g., notifying
customers of blackout restrictions or alternate programming requirements).
2) A device must support parental control.
a. Content delivered to the device must not be tuned or must not be presented if
restricted by Parental Control (PIN setting and resetting both via device and through
customer support, PIN enabling and disabling, PIN entry).
b. Adult title blocks.
c. Requirements: §§ 624(d)(2) and 640, 47 U.S.C. §§ 544(d)(2) and 560
d. Supporting standards: CEA-608, CEA-708, CEA-766.
3) A device should support Alternative Content.
a. The device must receive and insert appropriate content as alternate to regional
blackouts (sports, network non-duplication, syndicated exclusivity) or other
programming rights restrictions (e.g., in-home vs. out-of-home).
b. Customer notifications, including messaging, signaling & placement.
c. Advertising substitutions to accommodate content and channel ratings.
4) The device must support messaging and redirection for unauthorized channels.
5) The device must enforce copy control, image constraint, and selectable outputs control as
indicated by CCI or on-demand applications.
6) The device must enforce copy count limitations.
7) The device must enforce pass-through/regeneration of copy control information on outputs
(e.g., CGMS-a, APS).
8) The device must enforce/allow transit, delay/latency and round-trip time restrictions beyond
those defined by standards such as DTCP or HDCP.
DSTAC WG4 Report
August 4, 2015
53
9) The device must not deliberately filter out watermarks (video, audio, other). Watermarks, in this
case, are forensic markers embedded into a piece of content to permit after-the-fact detection
of the source of security breaches.
10) The device must enforce geo-filtering and geo-fencing requirements & restrictions beyond
blackouts (e.g., alternate programming).
a. E.g., restrictions/requirement for what can be displayed in common areas,
commercial/university properties
11) The device should support and must tolerate the presence of Active Format Descriptor (AFD)
signaling (e.g., letterbox, center-cut an HD signal to fit SD presentation).
a. Normative references: CEA-805, ATSC (A/65, A/81), SMPTE AFD.
12) The device must support transcoding or down-res’ing restrictions or requirements (e.g.,
minimum encoding bitrates/quality).
13) The device should support the feature of HD channel preferred.
a. When the subscriber tunes to a simulcast SD channel the device suggests tuning to the HD
version, or does so automatically if configured accordingly.
AUDIENCE MEASUREMENT
Audience measurement is the ability to report back viewing metrics based on anonymized census-level
audience data derived from set-tops. This is a non-intrusive service. Current audience measurement
techniques enable MVPDs to measure audiences for channels and when viewers tune in and tune out.
This helps to determine which programs are most popular, how many people watch a program to its
conclusion, what viewership to report to advertisers, which programs and channels to carry, how to
optimize programming to meet changing viewer demand, and how to sell advertising that underwrites
the programming and networks provider to consumers. Examples include: Audience measurement of
long tail and small market programming; Audience measurement to allow ad buyers to buy advertising
in specific dayparts and networks; DBS delivery of targeted ads based on household characteristics;
Consumer-packaged-goods companies measuring ROI by correlating campaigns with lift in sales.
PLAYBACK
This use case requires the activation of trick play capability of live TV, e.g. pause, fast forward, and
rewind, each at multiple speeds and may be enacted through the following methods:
● Time shift buffer
● Using local DVR
● Using network DVR
Pause and Resume are currently available and traditional features. The device and system should
support pausing content on one device and resuming from another device.
INSTANT CHANNEL CHANGE
Some MVPD devices support Instant Channel Change (ICC), a feature that minimizes or eliminates
channel change latency, depending on the MVPD’s network. A retail device for this use case should
support and include a variety of different methods of implementing ICC, including:
● IPTV – multicast and unicast RTP/UDP/IP
● QAM SDV
● Broadband tuners and demodulators
DSTAC WG4 Report
August 4, 2015
54
● Opportunistic device caching
● Pre-decoding of adjacent channels, with associated stream count limitations enforced.
REGULATORY REQUIREMENTS
There are a number of regulatory requirements for this use case. A device should support all service
provider and device regulatory requirements, as obligated by law. Examples of regulations include:
● Safety and interference requirements.
● Emergency Information
o Emergency Alert System (EAS) local and regional. Receives EAS on all channels.
Supports force tune and text crawls with audio replacement.
o Emergency Information: When emergency information is conveyed visually during non-
newscasts (such as in on-screen crawl), the secondary audio stream must be used to
convey such emergency information aurally, preempting any other use of SAP, such as
DVS or foreign-language.
● Accessibility Access (e.g., top-level vs. lower-level; ease of access)
● Advanced Communications Services (ACS), such as two way electronic messaging services (e.g.,
real-time text and video chat applications), must be accessible to and usable by persons who are
blind or have limited vision
o On July 1, 2016, the waiver of the ACS requirement is set to expire. The waiver includes
IP-TVs, IP-Digital Video Players (DVPs), and Set-Top-Boxes leased by cable operators.
● Nielsen
o Audio watermark pass-through
o ID3 tag pass-through and/or regeneration
● Commercial Advertising Loudness Mitigation (CALM) Act
● Pass-through of VBI (analog) (e.g., V-Chip, CC, VITC, etc.) and regeneration of digital counterpart.
Normative References:
● Accessibility: 47 C.F.R. Parts 14, 79; SMPTE ST 2052-1-2010, Timed Text Format (SMPTE-TT)
● CALM: 47 CFR §76.607; ATSC Recommended Practice (RP) A/85
● EAS: 47 C.F.R. Part 11
● Nielsen: 47 C.F.R. §§76.62; Carriage of Digital Broadcast Signals, 16 FCC Rcd 2598 ¶ 61 (2001).
● Privacy: 47 U.S.C. §§ 338(i), 551
● Pass-through & V-Chip: 47 U.S.C. § 534(b)(3); 47 C.F.R. §§76.62; 76.606; ATSC A/65 PSIP
standard; Carriage of Digital Broadcast Signals, 16 FCC Rcd 2598 ¶ 61 (2001); Second Periodic
Review of the Commission’s Rules and Policies Affecting the Conversion to Digital Television, 19
FCC Rcd 18279, ¶¶ 154-159 (2004).
● Parental control: §§ 624(d)(2) and 640, 47 U.S.C. §§ 544(d)(2) and 560
USE CASE #2 - Viewing On-Demand Content
USE CASE DESCRIPTION
This use case incorporates the features laid out within the Linear Content Use Case.
This use case also covers the multiple forms of on-demand content consumption, examples include:
DSTAC WG4 Report
August 4, 2015
55
● Transactional VoD (rental transaction, including purchase screen)
● Subscription VoD (premium subscription content, authorization only)
● Free VoD (non-premium content, no authorization or purchase screen)
● Electronic Sell Through (EST, purchase screen on first viewing only, authorization only on
subsequent viewing)
● Start Over™ (similar to subscription VoD, but contextual)
● Look Back™ (similar to subscription VoD)
● Purchase PIN (PIN setting and resetting both on TV and through customer support, PIN enabling
and disabling, PIN entry)
● Device meets trick play requirements, e.g. disables FF with OD content (typically during
advertisements), per content provider condition, disable skip (e.g., 30-second skip) for full assets
or intra-asset.
● 3
rd
party devices may purchase and display VOD from MVPD and OTT services via 2-way
agreements.
● 3
rd
party devices may support a purchase of MVPD provided content.
In satellite systems, each of these can furthermore be implemented via a priori staging of content on
local DVR storage. Devices interacting with DBS systems must accept catalog information from the
attached DBS gateway – depending on download history and broadband connectivity, any particular DBS
gateway will have unique sets of VOD content available. The variations in content and viewing window
will include variations of resolution (1080p/3-D/UHD/HD (1080i & 720p)/SD, etc.) and pricing.
USE CASE #3 - Tuning and Viewing Pay Per View (PPV) events
USE CASE DESCRIPTION
This use case incorporates the features laid out within the Linear Content Use Case.
This use case covers the purchase and viewing of PPV events including the following PPV features:
● Free preview window – period of time subscriber can view PPV event without paying.
● Purchase window – period of time subscriber can purchase the PPV event.
● Cancellation window – period of time during which subscriber can cancel the purchase of the
PPV event
● Secure purchase credits and purchase limits – In general, PPV event purchases are done on a
store and forward basis, purchases are stored securely, set-tops are provisioned with limits on
the number or amount of purchases that can be made before the purchases are collected
● User interface required to present time remaining in preview, purchase, and cancellation
windows, as well as the transaction and when the purchase limit is exceeded, including
messaging capabilities (e.g., call-in numbers, contact information)
● Purchase PIN (PIN setting and resetting both on TV and through customer support, PIN enabling
and disabling, PIN entry)
● Auditing and reporting
● Devices interacting with DBS systems must accept guide data from the attached DBS gateway –
accurate guide data is available for in-home use. The variations in content will include variations
of resolution (1080p/3-D/UHD/HD (1080i & 720p)/SD, etc.) and pricing.
● Limited time recording of PPV events on 3
rd
party devices may be supported.
● 3
rd
party devices must support a purchase UI controlled by the MVPD system.
DSTAC WG4 Report
August 4, 2015
56
USE CASE #4 - Navigation
USE CASE DESCRIPTION
This use case covers the broad range of methods for navigating linear and on-demand content.
Regardless of the method, the navigation must respect the content provider’s license agreements about
channel placement and neighborhoods. There is a significant effort that goes into the navigation to
optimize consumer satisfaction and make it easy to use / enjoy features of the service.
There are many different methods of navigating linear and on-demand content that should be
considered, some examples include:
● Provide a familiar or similar interface across the multiple devices consumers use to access the
service
● Grid guide
● Cloud based guide variants / RUI
● Talking guide
● Emergency Information settings & accessibility
● Closed Captioning settings & accessibility
● Channel presentation in required neighborhoods (e.g., news channels) and channel assignments
(e.g., broadcaster carriage on channel)
● Favorite channels, recent tuning history, bookmarks, etc.
● Recent tuning history across devices
● Mosaics & associated navigation
● Cover art
● Channel logos
● Thumbnails
● Search – including both locally-based and network-based
● Network-branded points of entry, e.g. content provider requires that their on-demand content
be accessible through a network-branded folder labeled “Disney” or “HBO” rather than just
being commingled with other on-demand content
● Multiple guide view…genre, by network
● Devices interacting with DBS systems must accept guide data from the attached DBS gateway –
accurate guide data is available for in-home use. Variations between particular homes will
include blackout and local channel availability, and will require a generated guide to accurately
reflect conditions in any particular subscriber’s home.
● Both HD and SD versions of channels may be available with otherwise identical service and
event information. Standardized table structures may not distinguish between 3-D, UHD, HD
and SD versions.
● Recommendations from user profile across devices
● Recommendations from what’s trending or popular in neighborhood
● Trick play – fast forward and/or rewind, at multiple speeds, skip chaptering, etc.
● Navigating and Billing for VOD including:
o Verification of purchase
o Offer of multiple options (e.g., rent or EST)
o Integration with billing system/account management
o Record customer purchases
● Search, including:
DSTAC WG4 Report
August 4, 2015
57
o Voice control via remote
o Voice control smart phone, tablet or similar device
● Whole Home capabilities:
o Ability to advertise services to the home network
o Ability to discover services on the home network
Multiple features above may be combined in the navigation functions.
USE CASE #5 - Recording Linear Content
USE CASE DESCRIPTION
This use case includes all of the features of the Linear Content Use Case and also covers the recording of
linear content via Digital Video Recording (DVR) capabilities. If recording rights are available for a
particular channel or event, then also see linear tuning use case for additional features.
There are a number of implementations that should be considered:
● Record on local hard disk drive
● Record on whole home DVR and supporting home network protocols
● Record on Remote Pause Buffer (Pausing Live TV from any STBs within the house)
● Record on Network or Remote Storage DVR (similar to subscription VoD, but on a per subscriber
basis, with associated database and navigation)
● Time-shift-buffering and limitations (e.g., restricted to 30 minutes)
● Record timers based on:
o Content type: first time airing, reruns
● Content removal incited by the timed recording.
o Content can be expunged based on settings related to number of recordings to keep,
priority, etc.
● Record on mobile device, side car recording
● Move recorded content onto an authorized device(s)
o A “move” removes the content from the source device. No copies are to be made in a
“move” scenario.
To support accessibility requirements and choices made during playback, 3
rd
party devices must
preserve all audio streams and associated metadata at the time of initial recording.
Recording rights may differ on a channel and/or event basis.
Recording rights may change over time and should be verified at the time of recording.
USE CASE #6 - Remote Management by Consumer
USE CASE DESCRIPTION
This use case covers management functions available to the subscriber remotely or on a network-
connected mobile device.
DSTAC WG4 Report
August 4, 2015
58
RELATED REQUIREMENTS
Management of Tuning
Management of the service by the subscriber remotely, including by the primary display and by a
network-connected mobile or second screen device:
● DVR scheduling
● Content search
● Remote control
● Parental controls, including device restrictions (e.g., by channel, rating, time-of-day, etc.)
● Management of some DBS gateways may require security certificates available from the MVPD.
Management of Account
Management of the account by the subscriber remotely, including by the primary display and by a
network-connected mobile or second screen device:
● Account management, pay your bill via integration with billing system
● Subscription management – ability to upgrade or downgrade service packages on-screen with
remote, requires access to service catalog and integration with the billing system
● Self-help customer service support items (e.g. schedule a service call or appointment)
● Subscriber Account Management may be supported on standard HTML5 web browsers that are
connected to an MVPD’s internet site.
● Account and password information should not be cached by an unsecure device or in
unsecured/unencrypted storage.
USE CASE #7 - Set-Top Box set-up
USE CASE DESCRIPTION
This use case covers how a subscriber can set-up a number of preferences for the operation of their set-
top box, including:
● Menu Preferences, such as changing the background darkness level and auto-tuning to HD
channels, overscan of image, on-screen overlays and their positioning.
● Device Settings
o Closed captioning
o Audio settings
o Light brightness of your set-top box
o Inactivity standby options
o Nightly reset time
o EPG preferences (size, favorite channel list)
o Remote control setup for 3rd party devices (TV, A/V receiver)
o Audio output format and volume leveling settings
o Control of HDMI-CEC for 3rd party devices (TV, AV Receiver)
o Output video resolution to TV:
▪ SD 480i
▪ ED 480p
▪ HD 720p
DSTAC WG4 Report
August 4, 2015
59
▪ HD 1080i
▪ HD 1080p
▪ UHD 2160p
● Parental Controls, see above
● PIN Controls, see above
● Accessibility (e.g., Closed Captioning, audio track selection, etc. – see above)
● Many settings and options will only be available through the MVPD device UI.
Management of Device
Management of the device settings by the subscriber, including by the primary display and by a
network-connected mobile or second screen device:
● Captioning
● Language selection
● Energy management
● Remote management and other tasks may require access to the video output or UI pages
generated by an MVPD device.
USE CASE #8 - Customer Support and Remote Management by Service Provider
USE CASE DESCRIPTION
This use case covers customer support and remote management features provided by the MVPD.
● Remote diagnostics
● On-screen diagnostics
● Ability to disable a device and display a notification (e.g. Call your service provider)
● Backup of set-top box configuration in the network (e.g. preserves DVR scheduling,
configuration preferences, etc.)
● Unified remote control experience
● Reporting back on statistics like signal level, device temperature and crash reports
● Software updates
● Some MVPD devices may save device and user settings in associated remote control devices.
● CSR support will require the subscriber to access the MVPD’s device UI and may require access
to raw video output of the MVPD device.
USE CASE #9 - Installation and Provisioning
USE CASE DESCRIPTION
This use case should describe the installation and provisioning of the service and customer premise
equipment necessary to receive the service. This use case should cover the range of installation from
self-install to professional install, and should include home networking setup of multiple display devices
(retail and MVPD/OTT) in the home.
This use case includes functionality to verify the quality of an installation (e.g. correct orientation of a
satellite dish) prior to allowing authorization of services.
DSTAC WG4 Report
August 4, 2015
60
● Ensure pre-requisites for service have been met by customer – i.e. network access setup and
configuration, Wireless network, home wiring, etc.
● If Ethernet over Coax technologies (i.e. HPNA or MoCA) are used, coaxial home wiring should be
tested before installing STBs to ensure proper network connectivity and throughput
● When wireless home networking is used, installers should verify rate, reach, Wi-Fi interference
to ensure high quality of service over Wi-Fi
● Secure Register with unique Consumer Device ID with backend systems to receive service
authentication and access data
● Ensure that customers are correctly provisioned for the services/packages they sign up for
● During installation verify the following:
o Service is up and running
o Remote control functions properly
o All services features (i.e. ICC, THDVR, etc…) and interactive applications are operational
● Some in-home network technologies will not interoperate with more than one MVPD present.
Parallel wiring may be required.
DBS-RELATED REQUIREMENTS
DBS systems need to be able to:
● identify the customer’s satellite matrix (which satellites are visible, and how to connect and
tune to them through a multiswitch),
● connect to “slim” clients within the house,
● prompt for STB authorization requests (e.g.,. call for authorization),
● Configure STB remote to control TVs, A/V Receivers, DVD/Blu-ray players that may be
connected to the system, universal remote setup, and configuration of IR-Blasters for control of
VCRs.
● Professional installation of service will require access to the video output (HDMI, Component,
composite) of provided gateway device.
● MVPD provided devices will require access to DBS broadcast to download current device
software.
USE CASE #10 - Device Operation Requirements
USE CASE DESCRIPTION
This use case covers additional features that normally run in the background, and are generally part of
maintenance, security, and efficiency interests. Such interests place requirements on the device, for
example:
Software Updates
Software updates for retail devices are typically the responsibility of the device manufacturer, while
software updates for MVPD provided devices are typically the responsibility of the MVPD. There are
some instances, for example DOCSIS cable modems purchased at retail, in which the cable operator may
assume responsibility for software updates to insure that network interoperability is maintained.
Methods by which software updates are disseminated and secured for retail devices is also typically
determined by the retail device manufacturer. Frequently, software updates for retail devices are
disseminated over the Internet, which assures two-way communication and permits validation of the
DSTAC WG4 Report
August 4, 2015
61
receipt and successful, secure installation of the software update on the retail device. Methods by
which software updates are disseminated and secured by MVPDs are specific to the MVPD, as well as
performed over the MVPD’s network. CableLabs specifies a secure software download mechanism as
part of the DOCSIS and PacketCable (VoIP) specifications. Secure software download is tested as part of
the certification of these devices.
Privacy and security
● Device secured against unauthorized access
● System requires court process for access by government
● Device must have required registered certificates for encrypted communications with backend
systems.
● Device must comport to FCC and FTC rules on privacy.
● May need to access raw video output during countermeasure checks.
Energy Efficiency requirements (Voluntary Agreement for set-top boxes)
Including configurability of sleep timers, inactivity & turn-off notifications
Meet consumers’ expectations of how well hardware and software should work together (i.e.
performance requirements)
USE CASE #11 – User Authentication
USE CASE DESCRIPTION
This use case covers the minimum requirements a device must comport to in order to authorize
transmission of content to an approved device.
In order for a device to receive specified content, the User and Device must abide by the following:
● Per the Precondition, the User has a subscription to a content service.
● The content service subscription authorizes connection to the content being accessed (e.g.
conditional access).
● The device must abide by the rules invoked by the content usage and security settings. Examples
include:
o Permissions
▪ Subscription will conform to region settings (neighborhoods, blackouts) and
service settings (entitlements).
▪ Device Authorization Access
▪ Content or application enforces applicable usage restrictions
▪ Rights Management
o Devices are required to track current version of DRM and security updates.
▪ Currently these updates are managed by the device and/or service provider
network.
In the event the conditional access permissions do not align, then the User should see a notification
message about this incompatibility and content will not be sent to the device.
DSTAC WG4 Report
August 4, 2015
62
USE CASE #12 – Renewability (DELETED DURING DELIBERATIONS)
USE CASE #13 - Cloud VOD Delivery
Pre-Condition: Subscriber has access to the same or similar VOD content that is available through the
primary Home Gateway or STB that the MVPD provides to the home subscriber.
USE CASE DESCRIPTION
This Use Case reviews the elements related to delivering content from a remote access, or cloud source
to a supported device. This is described in WG2 Report Part VI [45].
To support this use case a device should provide one or more of the following:
1. An App platform that provides support for multiple App developers including video distributors,
examples include: iOS, Android, Android TV, Tizen, WebOS, Yahoo Widgets, Xbox, and
PlayStation. The robustness of the App platform may affect what content is available to devices
that are supported by the the App platform.
2. An HTML5 based platform that supports Media Source Extensions (MSE) [57] and Encrypted
Media Extensions (EME) [58] with one or more Content Decryption Modules (CDM). As with the
App platform, the robustness of the implementation may affect what content is available to
devices that support HTML5 MSE/EME.
3. A DLNA VidiPath compliant client that can connect to an MVPD VidiPath server.
SERVICE DESCRIPTION
A Cloud VOD library typically also includes expanded VOD, such as look back content or episodic content
from previous weeks of a programmatic series. There may be different servers handling the home VOD
compared to the Cloud VOD media assets, thus not all content in the Cloud is offered at home and vice
versa.
Most implementations of Cloud VOD from MVPDs are growing to be a superset of the home use case for
VOD. Divisions of titles tend to be categorized in areas such as:
● Free
● Genre-based
● Network specific
● Premium Subscription
● Event-driven titles.
As Pay TV operators deploy HTML5 based UI’s, the MVPD subscriber can leverage a consistent UI across
the TV, mobile device, or PC. Content is typically accessed over the Internet using a Browser or Web
application. Platform dependent applications for iOS or Android are also being developed to provide
this TV Everywhere experience.
See also USE CASE #2 - Viewing On-Demand Content for IP VOD, which is already cloud based.
DSTAC WG4 Report
August 4, 2015
63
USE CASE #14 - Cloud Live Streaming
Pre-Condition: Subscriber has access to the same Live or Linear broadcast TV content that is available to
the primary Home Gateway or STB that the MVPD provides to the home subscriber.
USE CASE DESCRIPTION
This Use Case reviews the elements related to streaming the delivered content from a remote access, or
cloud source to a supported device.
To support this use case a device should provide one or more of the following:
1. An App platform that provides support for multiple App developers including video distributors,
examples include: iOS, Android, Android TV, Tizen, WebOS, Yahoo Widgets, Xbox, and
PlayStation. The robustness of the App platform may affect what content is available to devices
that are supported by the the App platform.
2. An HTML5 based platform that supports Media Source Extensions (MSE) [57] and Encrypted
Media Extensions (EME) [58] with one or more Content Decryption Modules (CDM). As with the
App platform, the robustness of the implementation may affect what content is available to
devices that support HTML5 MSE/EME.
3. A DLNA VidiPath compliant client that can connect to an MVPD VidiPath server.
Examples include:
● In the cases when a unidirectional DBS receiver is operating with access to the internet, cloud
VOD content available from the DBS MVPD is integrated into features such as navigation and
search on the DBS receivers to expand the scale and scope of the service offered to a DBS
customer. Both DBS MVPDs offer limited cloud-based live streaming content as alternative OTT
services using alternative navigation devices. In contrast to cloud VOD, this streaming content
generally duplicates what is offered through the DBS broadcast and is not also received by DBS
receivers.
SERVICE DESCRIPTION
Live or linear content is delivered at the time that the originally schedule content is delivered to the
subscriber’s home video gateway or STB. Access to these TV video streams tends to be sought from
mobile devices for the purpose of providing a TV Everywhere experience.
MVPDs offer applications that directly stream content from the Cloud using broadband access for home
devices such as gaming consoles, Smart TVs, and Tablets. The home user can avoid having to connect to
a STB with a wired HDMI cable. As MVPDs move to upgrade their network to a full IP distribution
architecture, these directly attached networked devices can receive a complete lineup of linear and live
TV content directly, without having to be tethered to a Gateway or STB.
USE CASE #15 – Cloud DVR Recording and Streaming
Pre-Condition: Subscriber has access to recorded content that is available from a Remote Storage DVR
service offered by the Pay TV provider, or access to a copy of the DVR content located on a home DVR or
Gateway device that is remotely stored in the Cloud.
DSTAC WG4 Report
August 4, 2015
64
USE CASE DESCRIPTION
This Use Case reviews the elements related to recording the delivered (via streaming) content from a
remote access, or cloud, source to a supported device.
To support this use case a device should provide one or more of the following:
1. An App platform that provides support for multiple App developers including video distributors,
examples include: iOS, Android, Android TV, Tizen, WebOS, Yahoo Widgets, Xbox, and
PlayStation. The robustness of the App platform may affect what content is available to devices
that are supported by the the App platform.
2. An HTML5 based platform that supports Media Source Extensions (MSE) [57] and Encrypted
Media Extensions (EME) [58] with one or more Content Decryption Modules (CDM). As with the
App platform, the robustness of the implementation may affect what content is available to
devices that support HTML5 MSE/EME.
3. A DLNA VidiPath compliant client that can connect to an MVPD VidiPath server.
SERVICE DESCRIPTION
Live or Linear broadcast TV content can typically be recorded simultaneously on both a local DVR and on
a remote server for access by a mobile device outside of the home. Control of the scheduling for
recordings can be done though a Web browser application running on a networked enabled device with
Internet access or using a Pay TV developed application, such as those downloaded for Android or iOS
devices. Remote control of the home DVR or remote control of the Cloud DVR is available through these
device MVPD applications. APIs may be provided by the MVPD for a retail device to use a third party
guide to control DVR content recording.
USE CASE #16 - Cloud Content Downloading for Mobile Devices
Pre-Condition: Use Case #15 has been met
USE CASE DESCRIPTION
This Use Case reviews the elements related to managing download content that has been delivered
from a remote access, or cloud, source to a supported device.
To support this use case a device must:
● Be an authorized device
● Maintain (i.e. no deliberately remove) content protection technologies that are inherent to the
downloaded content, such as Digital Rights Management or watermarks).
● If the downloaded content is marked with an expiration date, then the device must make every
reasonable effort to forbid playback of content once the expiration date has been reached.
● If the authorized device has a domain restriction imposed upon it, then the device must abide by
that requirement.
o Such a requirement is used to ensure that the device is tied to the subscriber’s home
network; protecting entitlements.
● Provide one or more of the following:
1. An App platform that provides support for multiple App developers including video
distributors, examples include: iOS, Android, Android TV, Tizen, WebOS, Yahoo Widgets,
DSTAC WG4 Report
August 4, 2015
65
Xbox, and PlayStation. The robustness of the App platform may affect what content is
available to devices that are supported by the the App platform.
2. An HTML5 based platform that supports Media Source Extensions (MSE) [57] and Encrypted
Media Extensions (EME) [58] with one or more Content Decryption Modules (CDM). As with
the App platform, the robustness of the implementation may affect what content is
available to devices that support HTML5 MSE/EME.
3. A DLNA VidiPath compliant client that can connect to an MVPD VidiPath server.
The availability of download varies among content subscription services; rights are often content or
programmer specific. Typically, the expiration date indicates how long the downloaded program is
available for playback.
Examples include:
In the case of a DBS service to a customer with no cloud access, it may be possible for the in-home DBS
system to act as a proxy for internet cloud-based content. This capability does not currently exist in any
fielded DBS STBs.
SERVICE DESCRIPTION
When available, a User has the ability to copy or move content from the Cloud for temporary storage
and manage content playback on a mobile device. Examples of this content may be VOD content or
copies of Live/Linear content stored in a Cloud DVR service. One reason that content is available for
download is to allow for offline viewing of subscription content. A device is considered “offline” when it
does not connect to a broadband network, wireless LTE service area or Wi-Fi access point.
Each service varies in how the downloaded content is managed. Examples of management methods are:
● Some require the device connect to a network after a certain number of days, in order to renew
rights and confirm expiration dates, other services do not require such check ins.
● When required, such as through rights limitations, one title is allowed to be checked out or
downloaded at a time per subscriber.
DSTAC WG4 Report
August 4, 2015
66
Part II: Systems that Enable Competitive Availability of Devices
Identify systems comprising minimum standards, protocols, and information other than security
elements to enable competitive availability of devices that receive MVPD services.
Section I: SAT-IP
Description
SAT-IP is a remote tuner control protocol that provides a standardized way for IP clients to access live
media broadcasts from satellite reception servers on IP networks. It separates distribution-specific
elements such as tuners, dish LNBs, etc into a single device that then provides video services to over IP
to client devices on the home network using common protocols. The client devices and protocols are
agnostic to the physical layer differences between satellite service providers. Satellite services can be
forwarded over all types of IP wired or wireless technologies to a range of IP client devices.
The protocol envisions a number of different possibilities for the server where it could be built-in to
different devices such as consumer or commercial versions of LNBs, IP Multiswitches, or set-top boxes.
Protocols
The SAT-IP home network protocols are based on IP, RSTP, UPnP and HTTP. It was made to be
integrated into DLNA as an option.
SAT>IP servers identify themselves on the IP network using standard UPnP mechanisms (SSDP). Stream
Control in SAT>IP is done via RTSP or HTTP. SAT>IP clients request access to satellites, transponders and
MPEG PID streams as needed. RTSP queries are used for requesting RTP unicast or multicast streams.
HTTP queries are used for requesting HTTP streams.
In summary, the client can provide low level tuning functions with the reception servers using this
protocol to translate to whatever specific technologies are used by the service provider.
Security
The solution current assumes either “Free-to-Air” unscrambled or a pass-through scenario that assumes
that any CA or DRM descrambling will be done by the client. Because the protocols can be used under
DLNA, DTCP-IP encryption could be applied to scrambled services. As a specification for use in Europe,
there is an assumption that DVB Common Interface + (CI+) would be used.
Information
The following links provide useful information:
http://www.satip.info/
http://en.wikipedia.org/wiki/Sat-IP
DSTAC WG4 Report
August 4, 2015
67
Section II: CableCARD
Description
The CableLabs CableCARD specification defines a two-way interface that is licensed to decrypt and view
one-way linear digital cable television in the United States. CableCARD only functions on Hybrid Fiber-
Coax (HFC) based networks and does not function on DBS or IPTV systems. CableCARD uses a physical
PCMCIA PC Card type II form factor device for all conditional access and provides copy protection of
content across the PCMCIA interface. A CableCARD is able to decrypt up to six simultaneous programs
from a service provider. A CableCARD set top box is comprised of the set top box, purchased at retail or
rented from operator, as well as the CableCARD itself which must be provided by an operator, generally
for a monthly fee.
At the core a set top box obtains a channel lineup from the CableCARD and then may request
entitlement to decrypt and display a particular program in the lineup. The CableCARD emits Copyright
Control Information (CCI) which the set top box Host is required to abide by, in cases such as recording.
Premium content requires a one-to-one pairing of CableCARD to Host to protect against unauthorized
viewing. Host binding requires an end user to contact their service provider with unique information
from both the Host device and the CableCARD, thus ensuring that all Hosts are licensed and certified
devices.
CableCARDS provide a few other mechanisms besides merely decrypting signals. The CableCARD
terminates and decodes the forward out-of-band channel which carries service information data such as
channel lineups (virtual channel map and source names), EMMs, software downloads, EAS messages,
and other control data, and proprietary service data. SCTE 65 defines six profiles for Service Information
tables for delivery via an out-of-band channel on cable, but if UDCPs wish to use guide data, then based
on the 2002 MOU and FCC Rule 15.123(b) retail UDCPs must obtain guide data through third-parties
other than the cable system.
The CableCARD provides an application information interface, which can be used to obtain information
about the CableCARD itself, including Host binding status, card manufacturer, card modes,
packets/tables received, et cetera. CableCARDs also provide a Man Machine Interface (MMI) that
provides a way to present messages on the display using HTML pages with URL's that are passed back to
the CableCARD to request further data from the MMI. The CableCARD specification defines a baseline
HTML profile that constrains the functionality required of the Host for the MMI. The Baseline HTML
Profile only supports formatted text messages, in the form of HTML pages, with one hyperlink. In
practice the MMI is only used for the Card/Host binding and diagnostic purposes.
Originally, CableCARD devices were either an integrated digital television with a CableCARD slot or a set
top box with video outputs only. A subsequent OpenCable Unidirectional Receiver (OCUR) specification
was developed to enable an interface to Microsoft Windows Media Center PCs. CableLabs eventually
offered additional secure IP output options and current CableCARD devices utilize them to distribute
video throughout the house. The OCUR Digital Receiver Interface is discussed in another section of this
DSTAC WG4 Report
August 4, 2015
68
document. The CableCARD ecosystem provides set top box implementors the ability to add features
consistent with the DFAST license, such as enforcement of content protection.
Standards
Standards in use by CableCARD include:
● SCTE 28 – Host POD interface describes low level CableCARD interaction, like the Man Machine
Interface (MMI), entitlement requests, application information, and other conditional access
related operations.
● SCTE 41 – Copy protection standards, includes key and certificate exchanges, device
authorization, content protection, Host binding, and algorithms in use.
● SCTE 65 – service information delivered out of band. Profiles 1-3 include virtual channel maps,
source names, and parental control. Profiles 4-6 are event information tables relating to guide
data.
● EIA-608/EIA-708/SCTE 21 – Embedded user data, such as CGMS-A content rights descriptor and
captions.
● Joint Test Suite.
Information
http://www.cablelabs.com
http://en.wikipedia.org/wiki/CableCARD
OpenCable CableCARD Interface 2.0 Specification, OC-SP-CCIF2.0, http://www.cablelabs.com/wp-
content/uploads/specdocs/OC-SP-CCIF2.0-I27-150330.pdf, Cable Television Laboratories, Inc.
OpenCable CableCARD Copy Protection 2.0 Specification, OC-SP-CCCP2.0,
http://www.cablelabs.com/wp-content/uploads/specdocs/OC-SP-CCCP2.0-I13-130418.pdf, Cable
Television Laboratories, Inc.
OpenCable Security Specification, OC-SP-SEC, http://www.cablelabs.com/wp-
content/uploads/specdocs/OC-SP-SEC-I08-110512.pdf, Cable Television Laboratories, Inc.
Uni-Directional Cable Product Supporting M-Card: Multiple Profiles, Conformance Checklist: PICS, M-
UDCP-PICS-I04-080225, http://www.cablelabs.com/wp-content/uploads/specdocs/DVC-RQ-M-UDCP-
PICS-I04-080225.pdf, Cable Television Laboratories, Inc.
Applicable Devices
● Most MVPD supplied cable boxes, excluding DTA's. (Requirement expires December 4, 2015).
● TiVO's
● Hauppauge/SiliconDust/Ceton network CableCARD tuners (OCURs)
● Ceton internal CableCARD PCI card
DSTAC WG4 Report
August 4, 2015
69
Section III: DRI and OpenCable interfaces (and specifications)
Description
An OpenCable Unidirectional Receiver (OCUR) is designed to be interoperable across all CableCARD
cable systems in the United States. The OCUR does not interoperate with DBS or IPTV MVPD systems.
The OCUR is designed specifically to work with a Windows-based PC with PlayReady DRM. The PC may
separately support OTT interactive applications, real time services, and other on demand services. OCUR
devices are unidirectional CableCARD devices, but an OCUR is defined as having IP outputs only with
DRM protection; physical video outputs are not allowed in this device model. The OCUR may optionally
have a USB interface host interface for connection of a Tuning Resolver. OCUR IP outputs are specified
by the Digital Receiver Interface (DRI). Various approved DRM systems are permitted to protect
premium content across the network; Microsoft PlayReady is the only currently approved full DRM for
the OCUR, while DTCP-IP is approved for link level security.
All client-server interaction leverages open standards and protocols, and adds additional DRI-
specified requirements, including a unique content protection layer (“DRI Security”) that must
be supported in all DRMs. Signal source and other CableCARD details are mostly hidden from
the receiving client, who only receives protected content streams and various ancillary
information externally.
Protocols
OCUR devices advertise themselves on the network using UPNP SSDP announcements. OCUR devices
offer two interfaces to obtain content using UPnP and DLNA protocols. An OCUR device supports the DRI
Tuner UPnP protocol, and optionally the DLNA Digital Media Server (DMS) function.
A Tuner object is available for each physical tuner the OCUR has. This DRI Tuner exports a variety of
operations and queries which closely resembles interacting with a physical tuner, this inferface allows
direct manipulation in cases of clear QAM. The interface also offers high level operations a user might
expect such as tuning to a linear digital cable channel. All data through this interface is transmitted via
UDP unicast streams using RTP.
An OCUR might also export a DLNA digital media server (DMS) content directory service (CDS). This CDS
allows for HTTP requests of streams and completely abstracts all details away from the tuner. The CDS
approach allows clients without an approved DRM access only to programs with Copy Control
Information (CCI) identifying them as Copy Freely, expanding the number of supported clients that can
access Copy Freely content to any device that supports DLNA.
Security
OCUR devices use IP for all outputs. OCUR devices can use either PlayReady or DTCP-IP for RTP
transmissions when using the DRI Tuner UPnP object model. OCUR devices encrypt all content that is
not Copy Freely, so the client is responsible for decrypting secure content. Programs accessed over
DLNA, which are not marked Copy Freely, can be secured using DTCP-IP or PlayReady. Any device which
DSTAC WG4 Report
August 4, 2015
70
is licensed to use Windows/PlayReady or is DLNA/DTCP compliant can interact and get content from an
OCUR device.
Devices that receive content from an OCUR device using Microsoft PlayReady must also conform to
OCUR license requirements managed by Microsoft for population of an Association Database of paired
CableCARD-OCURs, QoS, carriage of System Renewability Messages (SRM), Breach Management,
Revocation and Renewability, and indemnity. These supplement the license requirements for the OCUR
device itself.
Information
http://www.opencable.com
http://en.wikipedia.org/wiki/OpenCable
OpenCable CableCARD Interface 2.0 Specification, OC-SP-CCIF2.0, http://www.cablelabs.com/wp-
content/uploads/specdocs/OC-SP-CCIF2.0-I27-150330.pdf, Cable Television Laboratories, Inc.
OpenCable CableCARD Copy Protection 2.0 Specification, OC-SP-CCCP2.0,
http://www.cablelabs.com/wp-content/uploads/specdocs/OC-SP-CCCP2.0-I13-130418.pdf, Cable
Television Laboratories, Inc.
OpenCable Unidirectional Receiver, OC-SP-OCCUR, http://www.cablelabs.com/wp-
content/uploads/specdocs/OC-SP-OCUR-I11-130607.pdf, , Cable Television Laboratories, Inc.
OpenCable Digital Receiver Interface Protocol, OC-SP-DRI, http://www.cablelabs.com/wp-
content/uploads/specdocs/OC-SP-DRI-I04-100910.pdf, Cable Television Laboratories, Inc.
OpenCable Security Specification, OC-SP-SEC, http://www.cablelabs.com/wp-
content/uploads/specdocs/OC-SP-SEC-I08-110512.pdf, Cable Television Laboratories, Inc.
Applicable Devices
● Hauppauge WinTV network CableCARD tuners
● SiliconDust HDHomeRun network CableCARD tuners
● Ceton Windows Media Center Extenders
Section IV: Android/iOS Store Device Architectures from DEVELOPER
Point of View
Collectively, the app model is the means for bridging the differences between varied and rapidly
changing services and varied and rapidly changing consumer electronics platforms. These application
approaches abstract the diversity and complexity of service providers’ access network technologies and
customer-owned IP devices and accommodate rapid change and innovation by both service providers
and consumer electronics manufacturers. These application approaches may also make use of a
combination of software-downloadable security and a hardware root of trust. This diversity and
flexibility enables the broadest coverage of retail devices, optimizes the consumer experience on the
DSTAC WG4 Report
August 4, 2015
71
latest devices and technologies, and takes advantage of a wide range of market-tested security
measures including downloadable DRMs.
Table 8 shows how the major MVPDs currently support retail devices using this three-pronged approach.
All of the major MVPDs support an iOS and Android App to access their service on smart phones and
tablets. All of the major MVPDs support their service on Microsoft Windows and Apple Mac OS X either
through an application or a Web app (using a plug-in model for content protection today and
transitioning to an HTML5 EME Web App in the future). Some of the major MVPDs support Smart TVs
(LG, Samsung, Sony, Toshiba), game consoles (PlayStation 3 & 4, Xbox 360 & One), and media adaptors
(Roku). VidiPath Certification was launched in September 2014. Many of the major MVPDs either
support DLNA VidiPath today or plan to in the near future. DLNA RVU, developed and maintained by the
RVU Alliance, is supported by DirecTV. Certified VidiPath client devices are expected in the market later
in 2015. Table 8 lists some of the currently supported devices, which continue to grow.
DSTAC WG4 Report
August 4, 2015
72
Standards
By definition native apps are written specifically for a particular platform, e.g. iOS, Android,
Tizen, Xbox, Playstation, etc. While these platforms and devices make use of many different
standards, summarized below, the specific user interfaces, device features and platform APIs
enable differentiation and competition among them. This competitive marketplace for devices
and platforms has resulted in an explosion of smart phones, tablets and more recently smart
watches, with a large array of features and capabilities. Smart TVs are also offering application
platforms that enable access to new service offerings, including applications such as Netflix,
YouTube, and Amazon Prime Video, as well as some MVPD apps.
In general, these platforms offer some form of app marketplace (e.g. Apple’s App Store or
Google’s Google Play App Store), where MVPD app developers can offer their apps and
consumers can download them to their devices.
In order to support their App marketplace these platforms have developed various security
capabilities to insure that the content and applications are protected appropriately.
MVPDs have focused their app development efforts thus far on those devices and platforms that
enjoy the greatest consumer use and marketplace success. Table 8 ranks particular
devices/platforms by the number of units sold in the United States. As can be seen by this table,
MVPDs broadly support device/platform specific apps on the most popular devices/platforms.
MVPDs are also devising other ways to expand the range of devices and platforms that can
support MVPD apps, such as via an HTML5 web browser, VidiPath, or RVU. Some observations
that can be drawn from these and other marketplace facts:
● The total number of retail devices in the US that can be served by an MVPD app is over:
450 million devices
● The percentage of these retail devices that can be served by one or more MVPD apps is:
96%
● The percentage of these retail devices that can be served by an app from all of the top
10 MVPDs is: 67%
● The average number of MVPD set-tops per subscriber is 2.4
● The average number of these retail devices per US household is 4, well exceeding the
2.4 MVPD set-tops per subscriber
Other devices can be supported by either an HTML5 web browser, VidiPath, or RVU.
DSTAC WG4 Report
August 4, 2015
73
Retail Device
United States Units
MVPD Apps
Android phones
5
92,036,000
All top 10 MVPDs
6
PCs & Macs
w/Broadband
7
85,358,000
All top 10 MVPDs
iOS phones
5
71,449,000
All top 10 MVPDs
Xbox 360
8
48,460,000
5 of the top 10 MVPDs
Android Tablets
9
43,260,000
All top ten MVPDs
PlayStation 3
8
29,160,000
2 of the top 10 MVPDs
iOS Tablets
9
23,730,000
All top 10 MVPDs
Samsung TV
10
14,740,800
4 of the top 10 MVPDs
Vizio TV
10
12,151,200
0
Apple TV
11
8,800,000
N/A
Sony TV
10
8,764,800
1 of the top 10 MVPDs
PlayStation 4
8
8,650,000
2 of the top 10 MVPDs
Xbox One
8
7,790,000
2 of the top 10 MVPDs
LG TV
10
6,500,000
2 of the top 10 MVPDs
Roku
11
5,000,000
1 of the top 10 MVPDs
Chromecast
11
4,000,000
1 of the top 10 MVPDs
Total Number of Retail
Devices
469,849,800
Table 8- US Retail Device Numbers
Protocols
Some of the common standards that these platforms support include:
● IETF Internet Protocol Standards
● IEEE 802.11xx Standards
5
comScore Reports January 2015 U.S. Smartphone Subscriber Market Share, March 4, 2015 -
http://www.comscore.com/Insights/Market-Rankings/comScore-Reports-January-2015-US-Smartphone-
Subscriber-Market-Share
6
Top 10 MVPDs – AT&T, Bright House, Cablevision, Charter, Comcast, Cox, DirecTV, DISH, Time Warner Cable,
Verizon
7
Computer and Internet Use in the United States: 2013 American Community Survey Reports, U.S. Department of
Commerce Economics and Statistics Administration U.S. CENSUS BUREAU, November 2014 -
http://www.census.gov/history/pdf/2013computeruse.pdf
8
Platform Totals, VGChartz Limited, http://www.vgchartz.com/analysis/platform_totals/ (accessed: 6/18/15)
9
THE STATE OF THE TABLET MARKET - http://tabtimes.com/resources/the-state-of-the-tablet-market/ (accessed:
6/18/15)
10
Majority of US Internet Users to Use a Connected TV by 2015, eMarketer, June 13, 2014 -
http://www.emarketer.com/Article/Majority-of-US-Internet-Users-Use-Connected-TV-by-2015/1010908 and
Samsung, Vizio Control US smart TV market, Broadband TV News, MARCH 10, 2014 -
http://www.broadbandtvnews.com/2014/03/10/samsung-vizio-control-us-smart-tv-market/
11
Streaming devices sales in the United States in 2014 (in million units), Statista Inc. -
http://www.statista.com/statistics/296641/streaming-devices-sales-united-states/ (accessed: 6/18/15)
DSTAC WG4 Report
August 4, 2015
74
● 3GPP LTE Standards
● UPnP and DLNA Guidelines [60]
● W3C Standards
● MPEG video and audio standards
Information
MVPDs and OTT providers have developed apps for the following devices and platforms, among
others:
● Apple iOS
● Google Android
● Samsung Smart TV and Tizen
● LG WebOS
● Microsoft Xbox
● Sony PlayStation
● Roku
● Slingbox Client
The following sections discuss these platforms.
Apple iOS
Apple supports an app ecosystem for its mobile devices, smart phones, tablets, and smart watches
based on its iOS platform.
Apple has an extensive developer program for Apple devices that is accessible under license
(https://developer.apple.com/programs/). Apps can be submitted to the Apple iTunes Store for
distribution to iOS devices.
The iTunes Store, originally the iTunes Music Store, is a software-based online digital media store
operated by Apple Inc. It opened on April 28, 2003, and has been the largest music vendor in the United
States since April 2008, and the largest music vendor in the world since February 2010.
iOS (originally iPhone OS) is a mobile operating system created and developed by Apple Inc. and
distributed exclusively for Apple hardware. It is the operating system that presently powers many of the
company's mobile devices, including the iPhone, iPad, and iPod touch.
iOS was originally unveiled in 2007 for the iPhone and has been extended to support other Apple
devices such as the iPod touch (September 2007), iPad (January 2010), iPad mini (November 2012) and
second-generation Apple TV onward (September 2010).
The iTunes Store is accessible using a web browser, or using native applications on an iOS device. In
order to complete a purchase, one is required to register an account with Apple. This is a secure process
that every iOS customer needs to perform in order to be able to browse, download, install, and use any
of applications published through the iTunes Store. In order to create an Apple ID, one would need to
DSTAC WG4 Report
August 4, 2015
75
access the App Store and follow the steps that include entering contact information, email address, and
billing information.
Once a user account is created, the customer can browse all available applications, video, and music,
and make purchases. Applications are instantly available on the device.
The iOS platform allows applications to use HDMI and Airplay outputs to stream video and audio.
Content licenses may have different rules on allowing streaming over HDMI and/or Airplay. Given these
requirements, MVPDs are left to decide on allowing or denying access to high definition devices over
HDMI and/or Airplay. Requirements to manage HDMI and/or Airplay connections may be enforced by
the chosen DRM system.
The iOS platform provides the means of utilizing the underlying hardware security. All iOS devices have
a dedicated AES-256 crypto engine built into the DMA path between the flash storage and main system
memory, making file decryption very efficient. Application developers are free to use this mechanism or
implement their own. A summary of iOS provided hardware security is available at:
https://www.apple.com/business/docs/iOS_Security_Guide.pdf
Google Android
Google supports an App ecosystem for mobile devices, smart phones, tablets, and smart watches with
its Android platform. Google supports an App ecosystem for smart TVs with its Android TV platform.
Google also has an extensive developer program for Android Apps that is available under license to
Google (http://developer.android.com/index.html).
Google Play is the app store for the Google Android App ecosystem. Android is the operating
system created and developed by Google and, unlike Apple’s iOS, is available via open source for any
device manufacturer who chooses to licenseit. It is the operating system that powers many smart
phones, tablets, and media players. Use of the Android OS does not mandate distribution of Android
Apps through the Google Play Store. For example, Amazon has its own Amazon Fire Apps store for
Android apps that run on Amazon tablets and Fire TV media players.
The Google Play Store and Amazon Fire App Store are both accessible using a web browser, or using
native applications on an Android or Amazon device. In order to complete a purchase, one is required
to register an account with Google Play or Amazon.
Once a user account is created, the customer can browse all available applications, video, and music,
and make purchases. Applications are downloaded and made available on the device.
There are two integrated application development environments (IDEs) available for Android; Eclipse
and Android Studio with Java as the development language.
Google also provides a set of developer guidelines to assist in the development of Android apps, as well
as a set of design guidelines that help developers to make apps that not only work well but also look
good.
DSTAC WG4 Report
August 4, 2015
76
The Android platformprovides a secure boot process, as well as providing for signed application code,
although sometimes this can be device manufacturer dependent. Android provides application sandbox
support. However, Android does not provide a native secure media player, so an app developer must
implement a secure media player to meet its content license and regulatory requirements. Miracast
and/or HDCP protected output is often provided, but depends on the device manufacturer.
The Android App ecosystem is not as stringently managed as the Apple iOS app ecosystem. Android apps
are not strictly approved by Google and are self-signed only. Apps can be delivered from the Google
Play Store over Google protocols, or the Amazon Fire Store, or they can be side-loaded directly onto the
device.
The Android platform does not provide access to unique keys or certificated identities through Android.
However, access to the device MAC address is permitted.
Samsung Smart TV & Tizen
Samsung supports an App ecosystem for its smart TVs either with its Smart TV platform or more recently
its Tizen platform initially released in March of 2015 (http://www.samsungdforum.com/). During 2015,
Samsung Smart TV will fully migrate to the Tizen based ecosystem. The new Tizen platform will provide
for Samsung Smart TV App developers a better performing and easier app development
environment.The Smart TV platform supports Web applications, while Tizen supports Web applications,
native applications and hybrid applications, but Samsung Tizen TV only provides a Web application
environment for developers. App developers in Tizen develop applications based on Web technology
(HTML5, CSS3, JavaScript). Tizen also supports Samsung’s mobile devices, tablets, smart phones, and
smart watches.
Samsung Smart TV is a web-based application that runs on an application engine installed on Samsung’s
digital TVs that are connected to the Internet. Smart TV applications are special web pages
implemented in a web browser and displayed on a TV screen. Users can download Smart TV Applications
from Samsung Apps and install them on their TVs, or even develop their own applications.
Consumers can view an application on the TV screen similar to how they view web pages in a web
browser on a computer. However, the experience is adjusted to screen resolution, hardware
specifications, using the TV remote control for user interaction, and typically only executing one
application at a time.
The Smart TV platform supports HTML5, DOM3, CSS3, JSC, and a variety of DRMs including: PlayReady,
Widevine, Secure Media and Verimatrix. For transport the Smart TV platform supports DASH [40], HLS
[38], Smooth Streaming, as well as Live Streaming. The Smart TV Platform is based on two engines:
Gecko, for platforms from years 2011 and 2010 and WebKit [74] for more recent years. It supports
three resolutions:
● 960 x 540 pixels
● 1280 x 720 pixels
DSTAC WG4 Report
August 4, 2015
77
● 1920 x 1080 pixels
The Tizen platform supports HTML5, DOM3, CSS3, JSC, and a variety of DRMs including: PlayReady,
Widevine, Verimatrix, SecureMedia, SDRM, and SCSA. For transport the Smart TV platform supports
DASH, HLS, Smooth Streaming. Applications are signed with the developer certificate.
In order to distribute applications on Samsung TVs and make them available through the Samsung Smart
Hub Apps TV store, it is necessary to register the application and it must go through a certification
process provided by Samsung or its Affiliate at the Application Seller Office before being launched on
the Samsung Apps TV store. To request certification, it is necessary to prepare the Tizen widget package
and metadata and submit it in the Samsung Apps TV Seller Office.
To aid development Samsung provides both a development guide and a UX guide.
LG WebOS
LG supports an app ecosystem for its smart TVs with its WebOS platform. Applications are packaged in
IPK format and registered in the LG SmartWorld Seller Lounge. The LG application quality assurance
team evaluates the performance, function, and UIs of submitted apps to verify the suitability for
publishing on LG Content Store (LG STORE). Valid apps are published on LG Content Store (LG STORE).
Every app submitted to LG Smart World will go through a Quality Assurance (QA) process before sale is
permitted. Those Apps that do not meet the QA criteria can be rejected for sale.
The QA criteria applies to every app submitted but certain Apps such as game, video, education, etc, can
be subjected to additional criteria by category.
Apps that cause TV errors, illegally collect user information, contains malignant codes, and/or contains
viruses will be removed from the store, and the Seller can be held responsible.
Microsoft Xbox
Microsoft supports an app ecosystem for its Xbox game consoles, both Xbox 360 and Xbox One.
Roku
Roku supports an app ecosystem for its streaming video players, including its Roku 1, 2, 3, and Roku
Streaming Sticks. There is no fee for joining the Roku Developer Program or for publishing a Roku app.
Roku Channels are written in a Roku-specific language called BrightScript. BrightScript is a scripting
language similar to VisualBasic and is quickly learned by experienced programmers. Communication
with services and servers is done over HTTP using standard XML-based technologies like (M)RSS, RESTful
APIs and JSON. For video, Roku recommends H.264 video with AAC-LC audio wrapped in a MP4
container. Roku also supports the VC-1 video codec, and the WMA and MP3 audio codecs. Roku
supports the HTTP Live Streaming protocol (HLS) [38], which is quickly becoming the standard across
home entertainment and mobile devices. This technology provides adaptive streaming of either live or
on-demand content. Roku supports PlayReady for Smooth Streaming and AES-128 bit encryption for
HLS. Roku reviews and approves all apps prior to publishing them to the Roku Channel Store to ensure
DSTAC WG4 Report
August 4, 2015
78
that they are of high quality and function properly. Roku attempts to make this process as streamlined
as possible. The specific restrictions and terms for publishing content to the Roku Channel Store are
found in the Roku Developer Agreement. In a presentation to Working Group 4, Time Warner Cable
commented that the Roku developer support team was skeptical about developing a grid based EPG app
on Roku devices that would have acceptable performance. Based on Time Warner Cable’s extensive
experience in developing grid based EPG applications, they were able to provide an EPG app on Roku
devices that performed very well. This Roku app was demonstrated at the June 2, 2015 Working Group
4 meeting. {Link to video}
Applicable Devices
As outlined above Apps can be developed for almost every class of retail device, including:
● Smart or connected TVs
● Game Consoles
● Retail set-top boxes or HDMI sticks
● Personal computers (both Windows and Mac)
● Tablets
● Smart phones
Section V: VidiPath
The Digital Living Network Alliance (DLNA) is a technology standards organization with
participants from consumer electronics manufacturers, software developers, content providers,
and MVPDs that builds industry consensus to advance the interoperability of video products in
consumers’ connected homes. DLNA was founded in 2003 and currently has a membership of
more than 200 companies. DLNA’s multi-industry collaboration implements a set of guidelines
utilized by service providers, electronics manufacturers, and software developers to provide
consistent performance in a connected home environment.
“VidiPath” enables MVPDs to deliver their service to retail devices by using an HTML5 app with
extensions developed in the W3C standards body. VidiPath was developed in DLNA by major
retail device manufacturers (including Samsung, Panasonic and Sony); major chip manufacturers
(Intel and Broadcom) and major MVPDs (including Comcast, TWC, AT&T and DISH). The retail
device can operate as a retail “mall” in which many different video providers can operate as
retail stores presenting their own brands and experiences. The subscriber clicks on the app and
receives the full service offered by the MVPD. VidiPath Certified devices, include mobile
devices, PCs, set top boxes, AV receivers, game consoles, TVs. DLNA has also created a robust
certification program which tests and verifies the interoperability of products built to its
standards, ensuring consumers that devices branded with the DLNA Certified and VidiPath
Certified marks will successfully connect and exchange content. VidiPath service operator
services can be forwarded to all types of devices attached to the home network over wired or
wireless technologies.
DSTAC WG4 Report
August 4, 2015
79
With DLNA VidiPath certification and a “C2” flag in the DTCP certificate for LAN services or
commonName field with value "DTLA CVP-2 SP CA" in the X.509 certificate for cloud services,
service providers are guaranteed pixel accurate rendition of their user interface on devices and
with a good level of quality of service. VidiPath does not allow a competitive navigation device
to employ its own user interface to access MVPD content. There is no standard protocol for
discovering the list of premium channels, tuning to them, or recordings outside of the MVPD’s
remote user interface. The MVPD’s user interface is the only method for accessing content.
DLNA VidiPath enables both a home server model, or as MVPDs move more to the cloud, a
cloud to ground model. VidiPath does not facilitate retail device manufacturers the ability to
access to video content directly outside of the RUI.
This section presents an overview of the VidiPath specifications that include features such as
HTML5 Remote User Interface (RUI), Authentication, Diagnostics, Low Power, MPEG-DASH, and
DTCP-IP [60]. Benefits offered by VidiPath to consumers, OEM manufacturers and service
providers are also discussed. To support market adoption and implementation of VidiPath,
CableLabs has developed an open source implementation of VidiPath Server and Client
reference devices [56]. The main objectives for the VidiPath open source implementation efforts
are: provide reference devices to DLNA to help launch VidiPath certification program; provide
reference devices to the industry for testing and development of VidiPath products; and foster
VidiPath adoption and speed time to market. The Server and Client reference devices serve as
reference platforms for retail device manufacturers and MVPDs and other MVPDs to test their
VidiPath implementations.
Summary
To enable secure distribution of premium content from an in-home video gateway to retail
devices, major MVPDs in the U.S., CableLabs, retail device manufacturers and other service
providers all over the world, led an effort to define VidiPath specifications within Digital Living
Network Alliance (DLNA) [59].
DSTAC WG4 Report
August 4, 2015
80
Figure 19 - DLNA VidiPath Overview
Using VidiPath specifications, MVPDs can stream various content from a video gateway to retail
devices, such as TVs, game consoles, tablets, mobile phones, and laptops, with a consistent
MVPD user interface across different devices without the need of a dedicated MVPD supplied
STB per device.
The DLNA VidiPath Specifications define the following set of features for VidiPath Server and
Client [60]:
● HTML5 Remote User Interface (RUI)
● MPEG-2 and AVC media formats
● DTCP-IP Link Protection
● Diagnostics
● Low Power
● Authentication
● 3D Media formats; conditionally mandatory
● HTTP Adaptive Delivery; mandatory for Client, optional for Server
DSTAC WG4 Report
August 4, 2015
81
● Priority-based QoS
● Digital Media Server (DMS); mandatory for Server only
o No Content Directory Store (CDS) for linear content, VoD, or PPV is provided
● Digital Media Player & Digital Media Renderer; mandatory for Client only
Figure 20 - DLNA VidiPath Architecture
HTML5 Remote User Interface (RUI)
In order to support a consistent MVPD user interface to different form factors of retail devices
(e.g., TVs, tablets, mobile phones, and, game consoles) and requirements identified in the
Application Framework subsection, DLNA VidiPath specifications specify support for an HTML5-
based Remote User Interface. DLNA HTML5 Remote RUI specification defines a profile of W3C’s
DSTAC WG4 Report
August 4, 2015
82
HTML5 specification [39] and other related specifications such as Cascading Style Sheets (CSS),
Web Sockets, XMLHTTPRequest (Ajax), and FullScreen.
HTML5 is a widely adopted industry standard supported by a broad range of browsers on a wide
variety of devices. Thus, it enables MVPDs to develop their guide once and offer it on a wide
range of platforms resulting in reduced development costs and faster time to market for new
services/applications. It also enables MVPDs to offer their guides directly from the cloud,
thereby enabling them to rapidly evolve their services and applications to consumers.
An MVPD video gateway advertises that the Uniform Resource Locator (URL) of the MVPD
HTML5 guide and VidiPath devices discover the URL using the UPnP RUI Discovery mechanism
[63]. Cable operator’s HTML5 guide can be served either from the in-home video gateway or
from the cloud. Using the <video> tag defined in the HTML5 specification, MVPDs are able to
display video within their guide user interface pages. DLNA HTML5 RUI Specification defines
DLNA specific extensions to support playback of video content using <video> tag over an IP link
protected by Digital Transmission Copy Protection (DTCP). In addition, the DLNA HTML5 RUI
specification defines extensions to HTML5 <video> tag to support time-based seek and
playspeed trick modes so that a consumer is able to pause, rewind and forward the video from
the HTML5 guide page.
CableLabs developed a specification [64] that defines a standardized mechanism for exposing
information about MVPD regulatory and contractual services, such as closed captions, content
advisories, SAP, DVS, and ad insertion carried in the MPEG-2 TS video stream as HTML5 audio,
video and text tracks, so that MVPD HTML5 Web applications can provide these services to
consumers. DLNA HTML5 RUI requires implementation of this specification, so that MVPDs can
fulfill their regulatory and contractual obligations while offering the full MVPD service to
VidiPath devices. DLNA HTML5 RUI Specification also requires support for W3C’s Server Sent
Events (SSE) specification [65]. Using SSE, MVPDs are able to provide EAS messages to MVPD
HTML5 RUI applications running on VidiPath devices. Figure 21 shows various HTML5 RUI
entities and their functions.
Figure 21 - VidiPath HTML5 RUI Usage Model
DSTAC WG4 Report
August 4, 2015
83
HTML5 RUI (RUI-H) Source capability (+RUIHSRC+) has the role of exposing and sourcing RUI-H
content and includes RUI-H Server (RUIHS), RUI-H Transport Server, and an optional DLNA
Media Transport Server (for serving media content):
● RUIHS provides UPnP RUI Server device functionality, which enables VidiPath Servers to
offer one or more remote UIs based on HTML5, and to handle UPnP RUI Server service
actions.
● RUI-H Transport Server and RUI-H Transport Client are the device functions for transport of
the RUI-H content between a client and server.
● RUI-H Pull Controller (+RUIHPL+) has the role of finding and loading RUI-H content that is
exposed by a +RUIHSRC+ capability, rendering the UI content, and interacting with it. RUI-H
Pull Controller includes RUI-H Server Control Point (RUIHS-CP), RUI-H Transport Client, RUI-H
User Agent and an optional DLNA Media Transport Client.
● RUIHS-CP is a controller for browsing and selecting an HTML5 remote UI offered by a RUI-H
Server.
● RUI-H User Agent functionality on a RUI-H Client is responsible for retrieving, decoding,
presenting and interacting with the RUI-H content received from the RUI-H Server.
MPEG-2/AVC Media Formats
In order to support the full set of MVPD service features, retail devices need to support an
appropriate set of audio and video codecs with specific resolution, bit rate, and frame rate.
MVPD video content predominantly uses MPEG-2 video encapsulated in MPEG-2 TS, and
H.264/AVC in MPEG-2 TS to a lesser degree. In addition, support for adaptive bit rate streaming
needs to be considered as MVPDs may have a need to stream video over Wi-Fi networks to
portable devices. Support for MVPD contractual and regulatory services (e.g., closed captions,
parental control, EAS, SAP, and ad insertion) needs to be supported by this application
framework. Information about these services for video content is carried in-band as elementary
streams of the MPEG-2 transport streams (TS). So, the application framework needs to support
mapping of these elementary streams to the application layer. In order to enable rapid
application development cycle, the application framework needs to support a “write once and
run anywhere” model.
In order to ensure baseline interoperability between the VidiPath Server and the VidiPath Client,
the DLNA VidiPath specifications define a required set of Media Format profiles for both
VidiPath Server and Client for a particular geographic region (e.g., North America, Europe). This
set of media format profiles is representative of premium content sourced by service providers
in that particular region.
MPEG-2, as well as AVC/H.264 video encapsulated in MPEG-2 TS with resolutions up to 1080p,
are required. Support for audio codecs such as AC-3, E-AC-3, AAC, MP3, and MPEG Layer-1 & 2 is
DSTAC WG4 Report
August 4, 2015
84
required as a part of this media format profile set. Additionally, AVC video encapsulated in MP4
containers needs to be supported to enable interoperability with portable devices. VidiPath
Server and Client devices are also required to support DLNA specified trick modes (byte seek,
time seek and playspeed) and DTCP-IP link protection for this set of media format profiles. Due
to this mandatory set of media format profiles, as long as MVPDs offer their content using one
of the media format profiles from the VidiPath server implemented in the video gateway, a
VidiPath Client device will be able to play back the content over the home network.
DTCP-IP Link Protection
In order to meet content provider expectations and requirements, DLNA VidiPath specifications
leverage Digital Transmission Content Protection over Internet Protocol (DTCP-IP) Link Layer
protection technology to secure content from unauthorized copying and misuse within the
home as it is streamed from a MVPD video gateway to a VidiPath client device. DTCP-IP is a link
protection specification published by Digital Transmission License Administrator [66].
Figure 22 - Secure content transmission using DTCP-IP
This is a critical enabler for multi-device viewing experiences involving premium subscription TV
content. DTCP-IP is automatically negotiated between devices and has been designed to provide
certain content protection as content moves across the local home network. In accordance with
the VidiPath specifications, digital content can be shared securely between products in a user’s
home, but not with third parties outside the home network.
DLNA VidiPath Diagnostics
As premium video content is streamed over the home network from a video gateway to retail
devices, MVPDs need a mechanism to diagnose and troubleshoot home network related issues
remotely. Such a mechanism needs to support the ability to test the home network's
connectivity between a video gateway and retail devices, provide network topology, and
information about network throughput. In addition, the ability to query information about retail
DSTAC WG4 Report
August 4, 2015
85
devices such as device model, manufacture, and, firmware version needs to be enabled by this
mechanism.
The DLNA VidiPath Diagnostics feature focuses on the collection of data about the home
network conditions and devices through a set of actions and queries, so that a MVPD or a user
can take appropriate steps to troubleshoot and diagnose service-related issues. The VidiPath
diagnostics feature relies on UPnP Device Management [67] as a required functionality, and IEEE
1905.1 [68] as an optional functionality. UPnP Device Management provides the ability to collect
layer-3 & layer-4 diagnostics information such as IP-connectivity, network bandwidth, device
information, and device status. IEEE P1905.1 provides layer-2 diagnostics information such as
layer-2 link information, status, and layer-2 topology information.
Figure 23 shows various DLNA Diagnostics logical entities and their functions.
● A Diagnostics Endpoint (+DIAGE+) capability has the role of offering diagnostics services and
responding to diagnostics action requests by implementing UPnP Basic Management Service
v2 [69] as a required service and UPnP Configuration Management Service v2 [70] as an
optional service. DLNA VidiPath Specifications requires certain actions to be implemented,
such as Ping, Trace Route, and NSLookup. Both the VidiPath Servers and Clients are required
to support diagnostic Endpoint capability.
● Diagnostics Controller (+DIAGC+) has the role of providing a diagnostics application and a
control point for issuing action requests to a +DIAGE+. However, a Diagnostics Controller is
optional for VidiPath device profiles, although it is expected that a Diagnostics Controller
may be included on a VidiPath server to allow the service provider’s support staff to
diagnose issues within the consumer’s home. The diagnostics application drives the
Diagnostics Controller to access diagnostics data and capabilities. Cable operators remotely
access the diagnostics application running on the VidiPath server using a TR-069 or SNMP
management interface. Alternatively, a MVPD technician or end-user may access the
diagnostics application through a browser or screen interface as shown in Figure 23.
DSTAC WG4 Report
August 4, 2015
86
Figure 23 - VidiPath Diagnostics Architecture
Low Power
In order to meet consumer expectations and MVPD requirements for energy efficiency, MVPD STBs and
gateways implement energy saving operations, including various types of sleep modes. To avoid a
consumer having to explicitly wake up the video gateway when the consumer wants to watch video
content on a retail device, it is necessary that the retail device is able to wake up the video gateway
from sleep mode.
To account for service provider STB/video gateway devices implementing energy saving operations, e.g.,
different levels of sleep modes, the DLNA VidiPath specifications provide wake-up or reservation
mechanisms to VidiPath client devices. The specifications enable DLNA devices to convey energy
management and sleep-mode capabilities for each of its network interfaces. This facilitates the
awareness of the availability of DLNA functionality, even in the presence of power-saving mode
operations. The VidiPath Low Power feature is based on the UPnP Energy Management Service [71].
Power savings is modular within a physical device. In the context of DLNA networked devices, as shown
in Figure 24, each physical network interface can have various power modes. Some of these power
modes can allow layer-2 or layer-3 connectivity to still be present even when many other device
components are powered down. Other physical components, such as screens, hard drives and similar
resources, can also support different power modes.
DSTAC WG4 Report
August 4, 2015
87
The VidiPath Low Power feature consists of the following entities:
● Low Power Endpoint (+LPE+) capability implements UPnP Energy Management Service and
has the role of responding to action requests, including requests to provide information on
network interface mode, and requests to access services based on subscriptions.
● Low Power Controller (+LPC+) capability implements a control point for the UPnP Energy
Management Service and has the role of issuing action requests to a Low Power Endpoint or
a Low Power Proxy.
The VidiPath Server is required to implement Low Power Endpoint (+LPE+) capability, and the VidiPath
Client is required to implement Low Power Controller (+LPC+) capability. This enables VidiPath Clients to
query information about power save mode operations of a service provider’s VidiPath Server and invoke
appropriate actions to wake-up the VidiPath Server when its services are needed for the consumer.
Waking up a VidiPath Server from the low-power mode can introduce some latency and longer response
time, so it is expected that a VidiPath Client provides appropriate messages to the user to provide a
good user experience.
Figure 24 - DLNA Low Power Architecture
HTTP Adaptive Delivery
The HTTP Adaptive Delivery feature of VidiPath enables service providers to describe content as
adaptive content; i.e., in timed segments at various bit rates and in various media formats. In
the event of network congestion, which is likely to happen over Wi-Fi, a client rendering devices
can maintain smooth streaming of content for display by switching between streams at different
DSTAC WG4 Report
August 4, 2015
88
bitrates. A Media Presentation Description (MPD) file provided by a server includes segment
information such as timing, URL, and, media characteristics (e.g., video resolution and bit rates).
This feature leverages Moving Picture Expert Group Dynamic Adaptive Streaming (MPEG-DASH),
over HTTP (ISO/IEC 23009-1) standard [40]. Additionally, DLNA VidiPath specifications mandate
support for ISO-based media file format (ISOBMFF) Live, ISOBMFF On-Demand, and MPEG-TS
Simple profiles defined in the MPEG-DASH specification [40].
Different logical entities of the HTTP Adaptive Delivery feature are shown in Figure 25.
VidiPath Clients are required to support HTTP Adaptive Delivery device option and
aforementioned HTTP Adaptive media format profile. Support for HTTP Adaptive delivery is
optional for a VidiPath Servers, but if it is supported, then the VidiPath Server is required to
support at least one of the HTTP Adaptive media format profiles.
Figure 25 - HTTP-Adaptive Delivery Entities
On the VidiPath Server, the HTTP Adaptive Delivery device option has the role of exposing and
sourcing content using the HTTP Adaptive Delivery mode. This includes exposing and sourcing
both the MPD and the media itself (segments for different representations). This functionality
maps to the MPD delivery function and segment delivery function in MPEG-DASH. On the
VidiPath client side, the HTTP Adaptive Delivery device option has the role of requesting
appropriate content MPD and media representation (segments), and assembling and rendering
the media while adapting to changing network conditions.
Authentication
By utilizing the VidiPath Authentication feature, service providers can verify that the VidiPath
client has been certified to the DLNA VidiPath specifications. This provides confidence to service
providers that a VidiPath Client is able to display their HTML5 RUI guide, meet regulatory
requirements, and deliver content services appropriately to meet consumer expectations.
DSTAC WG4 Report
August 4, 2015
89
The VidiPath authentication feature also supports authentication of a VidiPath Server by a
VidiPath Client. A VidiPath Client can optionally authenticate a VidiPath Server to ensure that
the Client is talking to a legitimate VidiPath Server to protect consumers from rogue servers.
Upon DLNA certification of a VidiPath device (Client or Server), a device manufacturer obtains a
DTLA VidiPath Certificate, which has the same format as the legacy DTLA DTCP certificate used
for DTCP-IP link protection, except that it has a special field that indicates the device is DLNA
VidiPath certified. The same certificate is used by the device for VidiPath device authentication
as well as for DTCP-IP link protection. This avoids including additional certificates in the device
and saves cost for the device manufacturer. If a service provider authentication server is located
in the cloud, then it obtains a VidiPath X.509 certificate from DTLA.
DLNA VidiPath Authentication uses Transport Layer Security Supplemental Data (TLS-SD)
extensions, defined in RFC 4680 [72], to carry VidiPath client’s DTLA VidiPath certificate over
Hypertext Transfer Protocol over Transport Layer Security (HTTPS). Standard Transport Layer
Security [73] protocol only supports transport of X.509 certificates. A TLS-SD extension [72]
allows transport of arbitrary pieces of information over the TLS protocol.
The HTML5 RUI browser implemented by the VidiPath Client is responsible for performing
authentication using HTTPS with MVPD Authentication Server. Cable operator Authentication
Server verifies that the device requesting service is a DLNA Certified VidiPath device based on
the DTCP VidiPath certificate supplied using the DLNA VidiPath authentication protocol.
Error! Reference source not found. shows various VidiPath authentication logical entities:
Figure 26 - VidiPath Authentication Entities
● Client Authentication is a device option that supports client credentials and the protocols to
allow a client to be authenticated by an Authentication Server.
DSTAC WG4 Report
August 4, 2015
90
● Server Authentication is a device option that supports server credentials and the protocols
to allow a server to be authenticated by an Authentication Client.
The DLNA VidiPath Authentication supports two different scenarios for the Client/Server
Authentication:
1. In the first scenario, shown in Figure 27, the Authentication Server is in the cloud and
authentication must be accomplished with a cloud-based server. In this scenario, the
server uses trusted X.509 VidiPath certificate and client uses DTLA VidiPath certificate.
2. The second scenario is shown in Figure 28, where the Authentication Server is located in
the home (in a video gateway/STB) and all authentication protocol exchanges are
performed within the home network. In this scenario, the server uses trusted or self-
signed X.509 certificate signed with DTLA VidiPath certificate, and client uses DTLA
VidiPath certificate.
Other VidiPath Features
● Digital Media Server (DMS): VidiPath Server is required to support DLNA DMS device class.
This provides essential functions of device discovery, content streaming with support for
trick modes (pause, rewind, forward).
o There is no exported Content Directory Service (CDS) for access of video content
outside of the MVPD RUI.
● Digital Media Player (DMP)/Digital Media Renderer (DMR): VidiPath Client is required to
implement DLNA DMP and DMR device classes. These provide essential functionality for
content streaming with support for trick modes. DMR provides device discovery and “Play
To” scenario where a phone or tablet can establish and control content streaming between
a DMS and DMR.
● Priority-based Quality of Service (QoS): DLNA VidiPath requires prioritized QoS solution
where video streams are given a higher priority over data/background traffic over the home
network. The majority, if not all, of home networking technologies (e.g., Ethernet, Wi-Fi,
MoCA, HomePNA, and HomePlug) support traffic prioritization when packets are marked
with layer-2 802.1 p/q tags. The VidiPath Server is required to mark video packets with
diffserv codepoints (DSCP), as well as with layer-2 802.1 p/q tags, so that video traffic
receives appropriate priority when streamed over the home network.
MVPDs and content providers, want to ensure that their services are offered with the highest
quality when the content is streamed over the home network from a video gateway to retail
devices. Thus, it is necessary to avoid congestion or interference of home network traffic that
could degrade the quality of user experience. Therefore, it is necessary to consider that a video
gateway and retail devices support a home network technology with throughput in excess of
DSTAC WG4 Report
August 4, 2015
91
100 Mbps (enough to support 3 MPEG-2 video HD streams). In addition, support for either
priority-based or parameterized quality of service (QoS) needs to be considered.
● 3D Media Formats: DLNA VidiPath specifications conditionally mandate support for 3D
media formats for VidiPath Clients and Servers. DLNA has defined a set of frame-compatible
stereoscopic-3D media formats (Side-by-Side and Top-and-Bottom), which are
representative of content supplied by service providers. If the VidiPath client supports
rendering of 3D video, then it is required to implement support for these DLNA defined 3D
media formats.
VidiPath Deployment Scenarios
The DLNA VidiPath Specifications support two deployment scenarios: Hybrid In-Home + Cloud
scenario, and In-home only scenario.
In the hybrid In-home+Cloud Scenario, the MVPD’s HTML5 RUI server and authentication server
reside in the cloud, but all other functions of VidiPath server reside on an in-home video
gateway or STB. A VidiPath
Client discovers URL of the MVPD’s cloud guide from an in-home VidiPath gateway/STB. The
VidiPath Client is authenticated with a cloud Authentication Server, which may be co-located
with the cloud RUI server (server uses trusted X.509 VidiPath certificate). Upon authentication,
the VidiPath Client downloads MVPD HTML5 guide from the cloud. The HTML5 guide has links to
video content that point to the in-home gateway/STB. Thus, actual video content is served from
in-home gateway/STB to the VidiPath Client.
DSTAC WG4 Report
August 4, 2015
92
Figure 27 - Hybrid In-home + Cloud Deployment
In the In-home only deployment scenario, the MVPD’s HTML5 RUI server and Authentication
Server reside in the in-home gateway/STB along with all other VidiPath Server functions. A
VidiPath Client discovers URL of the MVPD’s guide from an in-home VidiPath gateway/STB,
which is served from within the home from the same gateway/STB. The same gateway/STB also
hosts the Authentication Server.
DSTAC WG4 Report
August 4, 2015
93
Figure 28 - In-home only Deployment
The VidiPath Client is authenticated with the in-home Authentication Server (the server uses
self- signed or trusted X.509 certificate signed with VidiPath certificate). Upon authentication,
the VidiPath Client downloads MVPD HTML5 guide to access content services from the in-home
gateway/STB VidiPath Server.
Standards
DLNA Guidelines, http://www.dlna.org/dlna-for-industry/technical-overview/guidelines [60]
Open Source Implementations of CVP-2 Server and Client, CableLabs, http://html5.cablelabs.com/dlna-
cvp-2/index.html [55]
Reference Device Kit (RDK), http://rdkcentral.com [56]
HTML5 - A vocabulary and associated APIs for HTML and XHTML, W3C Recommendation, World Wide
Web Consortium, http://www.w3.org/TR/html5/ [39]
RemoteUIServer:1 Service Template Version 1.01, For UPnP™ Version 1.0, September, 2, 2004,
http://upnp.org/specs/rui/UPnP-rui-RemoteUIServer-v1-Service.pdf [63]
Mapping from MPEG-2 Transport to HTML5, I03, CL-SP-HTML5-MAP-I03-140207, Cable Television
Laboratories, Inc. Specifications, Web Technology, February, 7, 2014 [64]
Server Sent Events, W3C Candidate Recommendation, 11 December 2012,
http://www.w3.org/TR/eventsource/ [65]
DSTAC WG4 Report
August 4, 2015
94
DTCP Volume 1 Supplement E, Mapping DTCP to IP, Revision 1.4 ED3, June 5, 2013, Digital Transmission
License Administrator, http://www.dtcp.com/documents/dtcp/info-20130605-dtcp-v1se-ip-rev-1-4-
ed3.pdf [66]
UPnP Device Management: 2, http://upnp.org/specs/dm/dm2/ [67]
IEEE 1905.1, IEEE Standard for a Convergent Digital Home Network for Heterogeneous Technologies,
2013, http://standards.ieee.org/findstds/standard/1905.1-2013.html [68]
BasicManagement:2, Service Template Version 1.01, For UPnP™ Version 1.0, February 16th, 2012,
http://upnp.org/specs/dm/UPnP-dm-BasicManagement-v2-Service.pdf [69]
ConfigurationManagement:2, Service Template Version 1.01, For UPnP™ Version 1.0, March 4th,
2013,http://upnp.org/specs/dm/UPnP-dm-ConfigurationManagement-v2-Service.pdf [70]
EnergyManagement:1, Service Template Version 1.01, For UPnP™ Version 1.0, August 30, 2013,
http://upnp.org/specs/lp/UPnP-lp-EnergyManagement-v1-Service.pdf [71]
ISO/IEC 23009-1:2012: Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part
1: Media presentation description and segment formats. [40]
S. Santesson, TLS Handshake Message for Supplemental Data, IETF RFC 4680, September 2006,
http://tools.ietf.org/html/rfc4680 [72]
T. Dierks, et al, The Transport Layer Security (TLS) Protocol, Version 1.2, IETF RFC 5246, August 2008,
http://tools.ietf.org/html/rfc5246 [73]
Gnome’s Rygel Project,
https://wiki.gnome.org/action/show/Projects/Rygel?action=show&redirect=Rygel
dLeyna Project, Intel Open Source Technology Center, https://01.org/dleyna
The WebKit Open Source Project, http://www.webkit.org [74]
The GTK+ Project, http://www.gtk.org
GStreamer, Open Source Multimedia Framework, http://gstreamer.freedesktop.org
Protocols
The protocols used include:
● UPnP
● TCP/IP
● HTTP
● HTTPS
● MPEG DASH [40]
Information
The DLNA VidiPath Guidelines can be obtained at: DLNA Guidelines, http://www.dlna.org/dlna-
for-industry/technical-overview/guidelines [60]
DSTAC WG4 Report
August 4, 2015
95
Applicable Devices
Any DLNA VidiPath certified device including: smart/connected TVs, game consoles, PCs, tablets, and
smart phones.
Section VI: W3C HTML5 Web Browser
The World Wide Web Consortium (W3C - http://www.w3.org/) is an open standards body that
defines the standards used to implement the Web today. HTML5 represents the latest version
of the W3C standards and is being implemented by all commercial web browsers today. Web
browsers for mobile devices are also implementing HTML5. Smart TVs and other connected
entertainment devices are also implementing HTML5 capabilities.
The HTML5 Media elements, Media Source Extensions (MSE) [57] and Encrypted Media
Extensions (EME) [58] are the W3C specifications for processing multi-media, including
protected audio/video content. All major web browsers are implementing Media elements,
MSE and EME to support both protected and unprotected video content. These specifications
are being adopted by video distributors across the Web. For example, Netflix already uses
HTML5 with EME to distribute protected content and other OTT distributers and MVPDs are
following their lead. HTML EME can also be used in devices that do not have browsers.
HTML5 Media elements are used to present video and/or audio data to the user. HTML5 media
resources can have multiple audio, video and data tracks. HTML5 includes standard definitions
for special media tracks, including alternative media, captions, descriptive audio, sign language,
subtitles, translation and commentary.
The MSE specification [57] defines an API that a web page can use to feed media data to the
HTML5 video or audio element. This API enables JavaScript in the page to:
● Handle processing of an adaptive media manifest file.
● Fetch the media segments using the URL from the manifest file
● Append the media segments for playback by the browser’s media player.
The MSE API can be used for insertion of other content like advertisements, alternative media or
playback of a local media file.
While the MSE API is independent of any particular adaptive delivery protocol, MPEG DASH [40]
has been a specific design and implementation focus. MPEG DASH takes advantage of the most
recent MPEG technology to seamlessly adapt to changing network conditions, and provide high
quality play back with fewer stalls or re-buffering events.
Media Source Extensions [57] enables JavaScript to send byte streams to the various media
codecs implemented in HTML5 web browsers. This allows the prefetching and buffering of
media streams to be implemented in JavaScript providing greater flexibility and application
DSTAC WG4 Report
August 4, 2015
96
control over these media streams. This flexibility allows the application to optimize the playback
of media from multiple sources. Figure 29 is the diagram of the MSE architecture from the W3C
MSE draft specification.
Figure 29- Media Source Extensions Architecture
The EME specification [58] defines an API that a web page can use to playback content, securely
protected by any EME-compliant DRM system, using the video or audio element. The API
enables the page to:
● Detect attempted playback of protected content.
● Learn what DRMs may be used to playback the content.
● Request the appropriate DRM license needed for content playback.
● Provide DRM licenses to the user agent for content decoding.
A browser may implement any number of DRM-specific content decryption modules (CDM) that
handle license processing and content decryption. EME does not specify any particular content
encryption or any set of DRMs, nor does it define how a CDM is implemented in the browser.
DSTAC WG4 Report
August 4, 2015
97
EME does require support for the Clear Key [61] decryption so that browser EME
implementations can be tested or used without a commercial DRM. EMEs is the W3C
specification that defines the APIs necessary to control the playback of protected content. Per
the EME specification:
“The API supports use cases ranging from simple clear key decryption to high value video (given
an appropriate user agent implementation). License/key exchange is controlled by the
application, facilitating the development of robust playback applications supporting a range of
content decryption and protection technologies.
This specification does not define a content protection or Digital Rights Management system.
Rather, it defines a common API that may be used to discover, select and interact with such
systems as well as with simpler content encryption systems. Implementation of Digital Rights
Management is not required for compliance with this specification: only the Clear Key system is
required to be implemented as a common baseline.
The common API supports a simple set of content encryption capabilities, leaving application
functions such as authentication and authorization to page authors. This is achieved by requiring
content protection system-specific messaging to be mediated by the page rather than assuming
out-of-band communication between the encryption system and a license or other server.”
Figure 30 shows the high-level architecture of the EME specification. In this example, content is
encrypted using Common Encryption Scheme (CENC) and is typically distributed from a Content
Distribution Network (CDN).
Figure 30- Encrypted Media Extensions Architecture
DSTAC WG4 Report
August 4, 2015
98
Error! Reference source not found. is the detailed EME architecture from the EME draft specification
and shows the APIs implemented to abstract the DRM implementations.
Figure 31 - Detailed EME Architecture with APIs
All of the major browsers have implemented EME, including Google/Widevine, Apple/Fairplay,
Microsoft/Playready, and Adobe/Access. Thus, there is competitive downloadable browser/DRM
marketplace.
World Wide Web Consortium (W3C) Standards
The W3C Specifications are publicly available at: http://www.w3.org/TR/. The following
W3C Specifications are relevant to enabling competitive availability of devices that
receive MVPD services:
● HTML5 - A vocabulary and associated APIs for HTML and XHTML, W3C
Recommendation, World Wide Web Consortium,
http://www.w3.org/TR/html5/ [39]
● W3C WOFF File Format 1.0. http://www.w3.org/TR/WOFF/
● W3C MSE, Media Source Extensions. http://www.w3.org/TR/media-source/ [57]
● W3C EME, Encrypted Media Extensions. http://www.w3.org/TR/encrypted-
media/ [58]
DSTAC WG4 Report
August 4, 2015
99
● W3C Crypto, Web Cryptography API. http://www.w3.org/TR/WebCryptoAPI/
[61]
Protocols
The protocols used include:
● TCP/IP
● HTTP
● HTTPS
● MPEG DASH [40]
Information
The W3C Specifications are publicly available at: http://www.w3.org/TR/.
Applicable Devices
HTML5 with EME and MSE is applicable to any device that implements these
specifications including: smart/connected TVs, game consoles, PCs, tablets, and smart
phones. HTML5 can support a browser user interface (e.g. Chrome or Firefox on a PC) or
HTML5 can support an application environment that looks just like a native app
environment (e.g. Smart TVs from Firefox OS, Tizen or WebOS). Consequently, HTML
EME can be used in devices that do not have browsers.
Section VII: RVU™
The RVU protocol is available to consumer electronics (CE) manufacturers via the RVU Protocol
Specification. RVU is based on open standards such as UPnP to simplify software integration
and enable cost effective solutions that CE manufacturers can leverage to create RVU clients
such as TVs.
RVU eases the provision of home networked commercial entertainment content while
heightening the user experience. Viewers can access either pre-recorded or live content,
premium content such as high definition or ultra-high definition video and multi-channel audio,
or personal content such as photos and videos via the media server. RVU supports a novel
process-light remote user interface that allows user interactions such as trick play (e.g., pause
and rewind) and the running of interactive applications.
In addition to a full featured remote user interface that allows the user of a connect client
device to navigate through user screens generated by a compatible RVU server, RVU technology
provides Internet Protocol (IP) connectivity, service discovery built from UPnP and DLNA
protocols, a remote commanding protocol, and industry standard media formats protected by
DTCP-IP content protection.
DSTAC WG4 Report
August 4, 2015
100
Standards
The RVU protocol specification is built upon UPnP device discovery, DLNA media streaming and
DTCP-IP content protection.
Protocols
The RVU remote user interface (RUI) protocol complements devices implementing content
streaming protocols of the DLNA guidelines [60]. The concept of a remote user interface for
clients is not new. However, the idea that clients should be able to provide a full-featured user
interface by implementing minimal functionality, leaving most of the “hard work” to the server,
is unique to RVU. The objective of RVU is to keep clients as process-light as possible. The RVU
RUI delivers bitmapped and/or vector graphic user interface data for a robust, consistent UI
experience throughout the home via thin clients as opposed to implementations with an entire
UI via client-side software. Clients implement relatively simple software to send key events to
the server and display the RUI graphics and video/audio received in response.
DSTAC WG4 Report
August 4, 2015
101
Information
The RVU Alliance is a non-profit technology standards alliance comprised of service providers,
consumer electronics manufacturers and technology providers to develop and maintain the RVU
protocol specification for a small footprint full-featured Remote User Interface (RUI). Board
level promoter members include Broadcom, Cisco, DIRECTV, Samsung and MaxLinear. Other
members are LG, Sony, Toshiba, Sharp Electronics, Dolby Laboratories, Humax, JetHead
Development Inc, Awox, MStar, Pace PLC, Sky Brasil, ST Microelectronics, Arris and Technicolor.
Applicable Devices
For a list of certified devices, including 4K/UHD clients, see www.rvualliance.org/products.
Section VIII: Passage
Description
Passage is a technology that enables security interoperability similar to DVB Simultcrypt. It is suitable
for broadcast linear streams where a service provider supports simultaneous distribution to receivers
with legacy Conditional Access (CA) and new security such as Digital Rights Management (DRM).
While the in-stream signaling for Simulcrypt and Passage are similar and the results are the same -
allowing receivers with different security systems to receive the same transport stream - it is
accomplished through different means.
Simulcrypt accomplishes interoperability through key sharing. The scramble key content is delivered
separately through proprietary means to receivers with different security systems. The content is 100%
encrypted and both systems share low-level descrambling capability.
However, key sharing may not always be possible or desirable. Legacy scrambling uses out-of-date
algorithms such as DVB Common Scrambling Algorithm (CSA), DES or DES-CBC. Often the security
extends into the descrambling by keeping certain information secret, e.g. Initialization Vectors for DES-
CBC or scrambling mode variations, to create anti-cloning mechanisms. Another anti-hack feature of
some legacy security systems is very rapid key changes which makes key sharing with other security
systems problematic.
Passage accomplishes interoperability through selective multiple encryption. A small amount of critical
content data, typically less than 2% of the bandwidth, essential for decompressing the rest of the
content (sent in-the-clear), is duplicated and scrambled two ways – one for legacy CA and one for DRM.
Each receiver gets the same transport stream, selects its respective scrambled content, and share the
remaining clear common content.
DSTAC WG4 Report
August 4, 2015
102
Figure 32 - Creation of Passage Selective Multiple Encrypted Stream
Unlike Simulcrypt, since Passage allows for the independent scrambling of critical packets of content,
there are the following benefits:
● The security of the large base of legacy receivers in the field is not put at risk.
o Divulging and licensing of the legacy descrambling know-how, e.g. Initialization Vectors, are
not required. This lowers the risk of inappropriate divulging of the information and also of
legacy clone hardware being available.
o Knowledge of a scrambling key leaked from the new security system cannot be used to
reverse engineer and attack the legacy security system. Alternatively, a key leaked from
the legacy security system cannot be used to attack the new security system.
o There is no need to “slow” key changes on the legacy system or share a higher level of the
legacy key derivation protocol thereby reducing overall resilience to a hack in order to be
compatible with the new security security.
● Since no secrets need to be shared between security systems, there should be no legacy CA
provider security indemnity concern for the service operator.
o Breaches should be readily identifiable as to which keys and which scrambled packets are
being hacked.
● The alternate packet may be scrambled using efficient implementations of the AES-128 algorithm
which may be more readily supported by DRMs and mobile device platforms.
● As with Apple HTTP Live Streaming [38], Passage’s use of selective encryption may make efficient
software-only implementations possible for new classes of devices and services.
● Legacy CA can be bypassed in new devices along with any licensing issues.
● Content rights need not be limited to the Copy Control Information (CCI) bits. Content rights
associated with the DRM encrypted alternate packets can maintain persistent control over content
by the service operator from broadcast to rendering – enabling new use cases.
Passage Headend Encoding
DSTAC WG4 Report
August 4, 2015
103
Figure 33 – Typical Digital Cable System Architecture
Passage Technology
Passage technology enables equipment from multiple vendors to be deployed on legacy digital cable
networks—without the need to duplicate content or bandwidth. Passage technology recognizes MPEG
compression as a form of encryption.
DSTAC WG4 Report
August 4, 2015
104
Figure 34 – Passage-enabled Digital Cable System
Passage technology supports multiple security systems, and it treats each security system
independently. Passage allows each security system to operate on its own encrypted data. As explained
in more detail later, Passage encoding carefully chooses the data that is encrypted. This process allows
multiple security systems to co-exist in an existing cable plant.
Passage technology supports DVB open standards. Support of DVB open standards allows
interchangeable headend equipment operation, and interoperability of multiple security systems.
New equipment adhering to the open standards architecture will process the data encrypted by the new
security system. At the same time, the legacy equipment, using proprietary methods, processes the
data encrypted by the legacy CA as before.
DSTAC WG4 Report
August 4, 2015
105
System Architecture
The Passage system architecture enables the deployment of field-configurable, modular systems.
Passage technology also avoids the geographical or spectral partitioning usually required when
introducing non-legacy components to an existing plant and the licensing or interoperability problems
associated with multiple CA systems. With Passage technology, there is no need for key sharing or CA
licensing. Secret proprietary information needed for descrambling need not be shared between the
legacy CAS vendor and the new security system.
Vital data, essential for decoding, is selected, duplicated, and encrypted in two ways: once for legacy
devices, e.g. STBs, and once for Passage devices, e.g. STBs, TVs, and mobile devices. Each device
receives the same transport data and appropriately selects its encrypted data. The remaining content is
shared by all devices. Only the critical data necessary for recovering video or audio content needs to be
encrypted. The Passage system only encrypts critical data. If a decoder cannot receive the critical data,
then the video image cannot be decompressed.
Figure 35 – The Headend Encoding Process - 4 Steps - Selection, Duplication, Encryption and Reconstruction
Managing Bandwidth
Passage recognizes that content might be treated differently based on the value of the content. With
this in mind, Passage is designed to allow the Multi-channel Video Program Distributor (MVPD) to adjust
the level of encryption on a per-channel and program-by-program basis. Passage allows the operator
control over packet encryption. The algorithms designed by Sony that choose critical data are
hierarchical and progressive and can be changed at any time. In addition, the modes used on each
program in a transport stream are completely independent of one another.
Thus a MVPD has the option of trading bandwidth for increasing degrees of robustness. The lowest level
of Passage encryption provides protection against decoding by commercially available MPEG decoding
DSTAC WG4 Report
August 4, 2015
106
devices. This mode carries the lowest bandwidth overhead, on the order of .2 percent. It is typically
used on content such as syndicated programs.
More robust protection for content with a higher value—such as VOD, live PPV events, premium
services, etc.—is provided with higher-level modes of Passage security. These higher-level modes carry
a larger bandwidth overhead; to a practical maximum of 2 percent for combined audio/video (see Figure
36). No significant increase in robustness is gained when increasing the total Passage replicated packet
bandwidth beyond 2 percent.
Figure 36 – Passage Bandwidth Usage
Implementations
Passage is proven technology. There have been a number of field and lab trials as well as deployments
with the Cisco CA Overlay system. As discussed in the Analysis Section of this report, the preferred
approach would be to Passage Encode content at the point of commercial distribution – prior to
reception by the MVPDs.
Security
While not a security system in and of itself, Passage use of selective encryption is approved by Merdan
Associates and Sarnoff Laboratories. Reports are available under NDA from Sony Electronics.
Protocols
Passage utilizes the DVB Simulcrypt standard to standardize interfaces at the broadcast center as well as
the signaling the security system in in-band stream. Additional messaging is required to signal the
alternate video and audio packets in a program. This is described in the “Passage Set-top Box
Specification”, available from Sony Electronics. Also see the “Passage Decoder IC specification” and
“Passage Test Streams specification”, available from Sony Electronics.
See also references [5], [6], [7], [8] and [9].
DSTAC WG4 Report
August 4, 2015
107
Part III: Alternative Systems that Enable New Categories of Navigation
Devices
The DSTAC WG4 has documented two systems for implementing a software-based
downloadable security system. Proposal 1: “Competitive Navigation”, was authored by multiple DSTAC
participants including Hauppauge and Google, and Proposal 2: “Application-Based Service with Operator
Provided User-Interface” was authored by multiple DSTAC participants including Cablevision, Comcast,
DISH, AT&T, Charter and MPAA. Following the systems are analyses authored by DSTAC members.
Section I: “Competitive Navigation” System
To support the operation of commercial competitive devices to receive all MVPD content on all MVPD
systems, as required by Section 629
12
and as a congressionally directed task,
13
DCAS solutions as
discussed in WG reports
14
should abstract the differences in MVPD network technology into a common
interoperable format. In an IP environment this is technically evolved, but conceptually similar to the
common, secure DFAST interface solution employed in the CableCARD solution presently relied upon by
both cable MVPD and third party sourced devices. An interoperable architecture implementing such a
system could provide for specific functional APIs plus a generic man/machine interface (MMI) that
allows devices to communicate through these defined APIs to interact with the DCAS, communicate
upstream and respond through private messaging, while supporting both a competitive UI and that of
the MVPD, as selected by the consumer.
Many MVPDs are in the process of migrating to (or simultaneously enabling) IP transmission of content,
through either direct Cloud to Ground delivery or an interim gateway solution that converts to IP in the
home.
15
As reported to DSTAC Working Groups, this has enabled the use of growing numbers of devices
that do not connect directly to or rely on the operator’s proprietary network technology. Transitioning
to IP technology will continue to entail the reliance on a number of network, encryption, codec, and
other technologies, so as to enable diverse choices and implementations, but also make the use of a
single, proprietary DCAS solution inconsistent with the operators’ present investments. The migration to
IP delivery by operators provides the technical opportunity for a common solution that relies on more
than a single implementation of DCAS while providing full access to MVPD content and services.
Competitive Navigation Device Executive Summary
To provide consumers with a third party, competitive device which 1) works across disparate MVPD
networks and 2) allows the user interface (UI) to differentiate itself from the UI provided by the MVPD, a
12
47 U.S.C. § 549(a).
13
DSTAC Charter, Dec. 5, 2014.
14
See WG1 Report, MVPD Requirements, Device Manufacturer Requirements; WG2 Report, Part III [45]; WG3
Report [descriptions of downloadable CAS systems].
15
[Comcast’s] Viper can handle all of Comcast’s multi-screen needs today but it can also be leveraged as the
company’s all-IP platform whenever Comcast is ready to cut over.
http://www.cedmagazine.com/articles/2014/03/comcast-uncoiling-viper-across-video-services
DSTAC WG4 Report
August 4, 2015
108
well-defined set of protocols and APIs between the MVPD system and the consumer device is needed.
This proposal for a competitive UI uses existing standards for these protocols and APIs, chosen so the
competitive UI can interoperate across all MVPDs in the U.S. Some of the proposed protocols and APIs
are derived from CableCARD specifications, and some are based on cable TV, broadcast TV or Internet
APIs and protocols.
This proposal gives consumers the same choices in television viewing devices that they enjoy today, and
expands that choice in experience beyond cable to other video service providers. The consumer devices
and technologies proposed in this section are conceptually similar to current consumer devices based on
CableCARD in that they receive TV content on one end, decrypt the TV content using the secure
technology (described by DSTAC Working Group 3), re-encrypt using an approved encryption scheme as
described by WG3 and then pass the encrypted data to the application which is creating the competitive
UI for recording or output through an HDMI port or a home network to other consumer devices.
To support this competitive UI, we describe three main interfaces inside the device: a Service Discovery
Interface, an Entitlement Information Interface and a Content Delivery Interface.
Service Discovery Interface: This interface provides the necessary information for the competitive
navigation device to discover and display the content services delivered by the MVPD headend and
provided to the subscriber. This includes the following functions:
● Lists of available services
● Metadata about those services
● Messaging from the MVPD
The Service Discovery Interface described in this document provides a common platform for publishing,
accessing, and searching metadata sources. In addition, an MVPD interactive “widget” is required for
service provider data and device information to be relayed to the end user, along with providing a way
to supply interactive widgets. Currently CableCARD provides a Man Machine Interface (MMI) which is
used to provide simple widgets for consumer devices. This proposal expands on the CableCARD MMI
interface to provide a bi-directional set of APIs based on HTML for MVPDs to send and receive
information from the competitive third party device. This provides a secure method for the MVPD’s to
retain control over part of the user interface and support functions such as Pay Per View, Service
changes, Billing and MVPD Upsell programs.
Entitlement Information Interface: This interface provides information on the entitlement status of the
services described in the Service Discovery Interface. It defines a common platform for publishing,
communicating, sharing and transferring rights information. A consumer device can be identified
through use of a standardized security certificate before obtaining rights information.
Content Delivery Interface: This secure, protected, interface delivers Live, Linear, VOD, and network DVR
content streams. It defines baseline requirements of the content formats (e.g. MPEG4), container
formats (e.g. MPEG2) and stream protocols (e.g. HLS) to ensure interoperability between the MVPD
DSTAC WG4 Report
August 4, 2015
109
system and the competitive device. This Interface also defines the content protection mechanism, and
secure transfer of metadata such as entitlement and copy control information. Suitable content
protection formats would be DTCP-IP or or another similarly approved secure digital ouptut.. The DCAS
system should terminate MVPD CAS/DRM (digital rights management) and translate the content into a
protected, interoperable format. This is how the CableCARD DFAST currently operates. CableCARD
DFAST shows that converting various network encryption technologies into a single common format
works with varying CA systems throughout the country, across all cable MVPD’s. Using this transcryption
approach, legacy systems do not require replacement in field, the DCAS and Provider Interfaces
transcryption operation handles this. Replacing legacy devices was a concern stated by multiple MVPD’s,
so this approach would allow for the easiest transition and could apply to newly deployed devices.
Diversity in Direct Connection Delivery Networks
As is documented in the DSTAC WG2 [45] report and in this WG4 report, there is a wide diversity in
delivery networks, conditional access systems, bi-directional communication paths, and other
technology choices across MVPDs.
16
It should not be necessary to disturb the potentially multiple
present and future CA/DRM system choices made by cable, DBS and IPTV systems, which leave in place
several proprietary systems for delivering digital video programming and services across MVPDs. Unless
all MVPDs replace these proprietary CA systems with some common and interoperable means of
termination, only such devices as are designed for these proprietary systems and authorized by the
specific MVPD can connect directly to the MVPD network to achieve full access. The only example in the
DSTAC record of an architecture through which comparable access to all cable MVPD programming can
be accomplished is that of CableCARD, which provides for diverse and upgradable or downloadable
point to point security but which also incorporates a common security termination and third party user
interfaces. The deficiencies of the CableCARD system are also well documented:
● It enables access only to cable systems.
● As licensed for third party use, it is forbidden to employ upstream signaling or provide access to
the operator’s UI.
● As employed in operator-leased devices it provides separability that is rarely employed.
● It was designed for cable architectures and infrastructure.
The DSTAC task is to recommend solutions that improve rather than recapitulate or degrade the existing
environment, in light of the deficiencies and coming changes to the CableCARD environment.
17
It would
16
WG2 Report Part III.
17
The STELA Reauthorization Act of 2014, which directed the FCC to establish DSTAC, effectively allows
cable operators to terminate their reliance on CableCARDs in leased devices in December of 2015. Commission
policy has been based on a conclusion that such common reliance will “align MVPDs’ incentives with those of other
industry participants so that MVPDs will plan the development of their services and technical standards to
incorporate devices that can be independently manufactured, sold, and improved upon” and make it “far more
likely that [MVPDs] will continue to support and take into account the need to support services that will work with
independently supplied and purchased equipment.” Implementation of Section 304 of the Telecommunications
DSTAC WG4 Report
August 4, 2015
110
not be a step forward or economically viable to require an environment in which, to offer access
comparable to that of MVPD-sourced devices across all MVPD programs and services a competitive
manufacturer would have to equip a device with RF tuners for cable and satellite, varied semiconductor
platforms to support the dozen-plus proprietary CAS technologies that may be used,
18
and IP
connections for IPTV implementation, and provide for all associated application and field testing. Nor is
it reasonable to expect that all operators will radically re-architect their networks, and converge on a
common solution for all direct connection, in order to avoid the obstacles to competitive solutions,
therefore an approach in which MVPD CAS is terminated and transcrypted to a common output format
is required to be least cumbersome on all parties.
Migration to IP Delivery Underway
Some MVPDs are putting significant effort and resources into defining IP protocols and working with
standards bodies and consortia such as DLNA, as well as testing/interoperability facilities such as
CableLabs
19
. Many MVPDs have been actively working on protocols that support either direct “Cloud to
Ground” delivery, or interim gateway solutions that convert to IP in the home.
20
Under the Cloud to
Ground model an operator terminates its proprietary network so as to interface with the user’s home
network over IP. Such termination devices are often called data gateways, or simply “gateways.”
Examples include DOCSIS modems on Cable plants and DSL modems or Optical Network Terminals (ONT)
on Telco and Fiber IPTV systems. The MVPD’s services are then made available over the IP home
network using standards-based protocols to various consumer devices. The consumer devices do not
need to implement any network-specific technology such as physical tuners.
In an interim gateway model, the MVPD provided direct-connect termination device converts video
services to IP in the user’s home instead of upstream in the MVPD’s network. For example, VidiPath and
RVU servers can translate a variety of access technologies into common IP protocols. Cable and DBS
operators have demonstrated and fielded RUI technologies through gateway devices as solutions that
provide content services to non direct-attached devices, such as SmartTVs and tablets. These devices all
use IP protocols over home networks to provide content and information to other devices in homes.
Many MVPDs already have equipment in consumers’ homes that may theoretically be convertible to an
interim gateway by enabling the Ethernet interface already on the device.
Act of 1996; Commercial Availability of Navigation Devices, 20 FCC Rcd 6794, 6802-03, ¶ 13 (2005) (“2005 Deferral
Order”), pet. for review denied, Charter Communications, Inc. v. FCC, 460 F.3d 31 (D.C. Cir. 2006), as cited in
MO&O, Colorado Tel. Co. et al, July 23, 2007, par. 3 and n. 17.
18
[WG3 cite]
19
The VidiPath Interoperability lab provides an opportunity for VidiPath Client manufacturers to develop,
test, and capture pre-certification videos while interoperating with VidiPath servers from major MSOs.
http://www.cablelabs.com/resources/development-lab/
20
Comcast’s Cloud-Based UI Makeover, http://www.lightreading.com/cable/cables-cloud-based-ui-
makeover/a/d-id/716978
DSTAC WG4 Report
August 4, 2015
111
Limitations of Architectures Thus Far
A migration to IP enables an interoperable architecture in which MVPD CA systems terminate in ways
that can support competitive devices across MVPD service categories, as well as over diverse CAS
implementations within categories. Such architecture can support product innovation and
differentiation, which can be competitively decisive.
21
However, solutions such as VidiPath and RVU
appear to have been deliberately designed to not allow a fully independent user experience on
competitive devices. There are no apparent specifications that describe how another device can obtain
all the necessary information needed to create a competitive user experience. Rather, they are aimed at
“consistency” of a single MVPD user experience across various devices.
The current approach to monolithic presentation of an MVPD’s user interface through a remote UI
technology like RVU and VidiPath can be supplemented or extended so as to also allow an independent
(not controlled by the MVPD) client-side user interface to access the audio and video content and micro-
services presented in an MVPD’s user interface. For example DirecTV already extends RVU to allow
client control over the server through a RESTful approach, called the SHEF protocol. With SHEF, a client
application or user interface can launch RVU and tune to a channel, a feature that DirecTV enables via
an HTTP server embedded and tied to the RVU server. And, being based on http protocol, this approach
can be extended to cloud solutions also. Additional extensions would be required to support a full
competitive navigation system however. Similarly, VidiPath, which may have a different combination of
LAN and cloud delivery of content and services, could be extended to enable independent client user
interfaces using a RESTful approach. With VidiPath, the HTTP server may be located in the cloud or on
the home network but either way should provide to the client a method to browse, select and launch
the content items or micro-services provided by an MVPD through VidiPath. Unlike RVU, which is
primarily a push technology, the VidiPath client often pulls content from the server. In this case, the
HTTP server may be supplying a URL extension (like a query parameter) that the VidiPath client then
uses to pull content or micro-service. A local application or user interface can then launch its VidiPath
client with the extended URL information without navigating through the monolithic guide. And, since
VidiPath mandates support for HTML5 push technologies like Dynamic HTML, AJAX, Web Sockets and
Server Sent Events, an MVPD may choose an approach more closely resembling how SHEF works with
RVU. Separating the control and data planes as in these examples of extensions to current MVPD efforts
so as to support a competitive UI would be necessary to support third-party implementations. Some
problems currently preventing VidiPath, HTML5 EME and RVU from being suitable interface protocols
for an independent third party to utilize are detailed here:
21
See, e.g., Slade Kobran, How To Differentiate Yourself When You’re Not That Different,
http://www.chiefoutsiders.com/blog/bid/99344/How-To-Differentiate-Yourself-When-You-re-Not-that-Different
(“Apple’s … focus on both the physical appearance of its devices and their user interfaces have turned Steve Jobs'
passion for design and simplicity into the most valuable company in the world.”)
DSTAC WG4 Report
August 4, 2015
112
● VidiPath uses an array of protocols with which a third party client device may communicate with
the server. However, VidiPath as currently defined does not meet the requirements to enable
competitive navigation devices. In particular VidiPath:
● Does not allow for discoverability of the video services such as linear channels, VOD and PPV
● Does not allow for an independent user interface to access most content directly, such as
VOD, PPV, and network DVR - all content is available exclusively through the MVPD’s
VidiPath RUI
● Does not allow independent clients to record streams
● Does not allow independent clients to navigate to and schedule a recording
● Does not provide independent clients details on entitlements for video services
● RVU offers similar functionality to VidiPath, but supports different operational interfaces.
However it shares some of the same limitations that do not allow for a competitive third party
user interface that can directly access content.
◦ The RVU protocol’s utility for supporting third party devices is limited by a requirement to
licensing guide data to interoperate with current devices, and an inability to record through
the user interface.
◦ It does not provide standard APIs for an independent application to obtain the list of
available services and available assets
◦ It does not allow an independent application to record live content
● HTML5 EME, MSE and WEBCRYPTO define a set of protocols that enable a HTML5 application to
access embedded browser security elements to enable downloadable security. However they
are not sufficient to enable a competitive navigation user experience on the client device.
◦ Only monolithic applications from the MVPD that integrate both user experience and
security are currently supported. There are no interfaces that allow competitive user
interface applications to access the same security APIs as the MVPD’s proprietary
application.
◦ There is no clear definition of what requirements are mandatory in the browser to support a
MVPD’s given choice of downloadable security. For example currently each popular browser
supports only one DRM under EME. Unless each MVPD offers support for every DRM, a
retail device can’t be guaranteed access.
Limitations Where User Experience Is Too Closely Controlled
Common interfaces and defined protocols, as implemented through CableCARDs, are necessary but not
sufficient to support and sustain competition by third party devices. In case of the OCAP [23] (aka
“tru2way”) architecture, allowing upstream communication through a CableCARD was conditioned on
business requirements antithetical to a competitive experience. The architecture required that the
MVPD control all software related to two-way cable services, forestalling any ability for a third party
device to offer its own UI to access two-way services. Moreover, manufacturers were unable to assure
that MVPD-deployed software would operate as predicted. Such outcomes are not inevitable. Defined
protocols between layered components have successfully enabled innovation in devices and networks.
They are foundational to the Internet and have been highly successful at bringing services and devices to
DSTAC WG4 Report
August 4, 2015
113
market rapidly. The use of protocols can minimize requirements for network and device
interoperability, and does not impose requirements on internal implementation of the devices
themselves to support the protocols. Such architectures avoid the necessity to mandate and test
detailed, internal operations of individual MVPD systems.
Hence this proposal focuses on interfaces for an interoperable architecture, and defined protocols that
enable full innovation of the consumer experience. This section outlines such an architecture.
Interfaces Necessary to Enable Competitive Interoperability
To enable competitive navigation devices and user experiences, an architecture should provide
1. information on video services available to the consumer and devices
2. access to content over a common network interface
3. entitlement and usage rights information of the available services
We call these the Service Discovery Interface, the Content Delivery Interface, and the Entitlement
Information Interface. These Provider Interfaces would be offered by each MVPD in a common defined
standard, but the DCAS and other elements that the MVPD chooses to implement them are left up to
the MVPD to allow for continued innovation and diversity in implementations.
Each Provider Interface can be defined in a set of interfaces with defined protocols and formats.
Standard Internet protocols would be used, all built on top of TCP/IP and HTTP. The formats would use
standards such as XML for data exchange, HTML for graphics, common codecs for audio and video
content such as MPEG-4, etc. These protocols and formats are common to most networked consumer
devices today. This proposal defines required functional interfaces and outlines various similar
technologies that exist, but recognizes current standards cannot be used directly without evolving in
some cases.
Service Discovery Interface
This interface provides the necessary information for the competitive navigation device to discover and
display the content services delivered by the MVPD headend and provided to the subscriber. A common
protocol across MVPDs allows competitive devices to work across MVPDs. For example in the
CableCARD architecture, service information is delivered in text tables defined in a SCTE specification.
22
The navigation device can then display this service and content information in any chosen format such
as a grid guide, series of recommendations, or a visual mosaic. The interface provides the list of services,
and sufficient metadata to uniquely identify the content in each video service to the user.
Content Delivery Interface
22
ANSI/SCTE 65 2008 “SERVICE INFORMATION DELIVERED OUT-OF-BAND FOR DIGITAL CABLE TELEVISION”
DSTAC WG4 Report
August 4, 2015
114
As noted in the WG2 report [45], MVPD content formats and CA/DRM systems vary. In this interface the
provider implementation and DCAS components terminate the network CA/DRM and translate them
into a finite set of defined, interoperable formats. Both CableCARD and DLNA systems define such
interfaces today. For example by defining a finite set of defined formats, DLNA and CableCARD
frameworks ensure portability across MVPDs and across content service types. Note that content here
described also includes optional and mandatory ancillary streams such as multiple audio tracks and
closed caption data.
Entitlement Information Interface
This interface provides the competitive navigation device information on the entitlement status of the
services described in the service discovery interface. For example in the CableCARD system, the
ca_pmt() Application Protocol Data Unit provides information on whether the device is authorized for a
particular service. Entitlement implies some form of authentication of the device and/or user by the
DSS.
Each of the interfaces is described in more detail in the following sections.
The following diagram, based on the one in WG3’s report, illustrates the interfaces that are provided
from the provider to consumer devices. The interfaces are labeled Interface C, D and E in the diagram.
DSTAC WG4 Report
August 4, 2015
115
Figure 37 - Interfaces
Physical Interconnection and Basic Networking
The Provider Interfaces shall be implemented by the MVPD using open standards. The physical
interconnection standards for home networks are grouped under the IEEE standard 802
23
. The standards
specifically involved with wired Ethernet fall under the 802.3 subheading.
Standards for the software layers of home networking are promulgated by the Internet Engineering Task
Force (IETF
24
) through the RFC (Request For Comment) mechanism. For instance, RFC 1122
25
describes
the basic TCP/IP protocols that universally underlie the Internet. A large number of open-source
implementations of these protocols are available. HTTP, the foundation for web browsing is
standardized as RFC 2616
26
, which is carried by TCP/IP. In the simplest home networks, RFC 3927
27
is
used to automatically configure the gateway and third-party devices on the home network. More
23
http://standards.ieee.org/getieee802
24
http://www.ietf.org
25
http://tools.ietf.org/html/rfc1122 - Requirements for Internet Hosts -- Communication Layers
26
http://tools.ietf.org/html/rfc2616 - Hypertext Transfer Protocol -- HTTP 1.1
27
https://tools.ietf.org/html/rfc3927 - Dynamic Configuration of IPv4 Link-Local Addresses
DSTAC WG4 Report
August 4, 2015
116
sophisticated consumers may have DHCP (Dynamic Host Configuration Protocol) servers on their
network (for instance, in a wireless router) which configures the network, as described in RFC 2131
28
.
Service Discovery Interface
This interface provides the necessary information for the competitive navigation device to discover and
display the content services delivered by the MVPD headend and provided to the subscriber. This
includes the following functions:
● Lists of available video services
● Metadata about those services
● Messaging from the MVPD relating to these services
The two required operations of the basic Service Discovery Interface implementation are: interface
detection/advertisement, which allows an Interface to announce its presence to consumer devices on
the home network; and service browsing, in which a consumer device can browse and access the
available services and metadata from the MVPD.
Interface Detection
It is important that consumer devices be able to automatically detect the Provider Interfaces on the
home network, as well as automatically discovering what services are available. A gateway device
typically advertises the services it makes available on the local network via an Internet standard suite of
protocols called Zeroconf
29
, such as Avahi
30
. The Provider Interface can present certain defined URLs
across MVPDs that support the interfaces described here, with the IP address of the URL described in
the service announcement. This could be supported in both the gateway and cloud to ground model
implementations of the Provider Interfaces. In the case of bidirectional systems, because the Interfaces
are provided on the MVPD’s managed network, the MVPD can ensure that the interfaces are only visible
to their customers.
Service Types
While many different services are possible over time and can be added by extensions to the interface
protocol, this proposal envisions two basic services: linear broadcast/multicast video (i.e., digital
television), and unicast video-on-demand. In each case, the metadata describing available video
services would be accessed from an MVPD source directly by a consumer device using standard
protocols. In addition to discovery of linear services, available PPV and VOD services should be
accessible via the same format.“Pay Per View” content availability transitions require higher precision
and frequency, but content could be otherwise transported similarly to channel-based content. Both
PPV and VOD purchases will require some sort of audit trail. While phone/web/online purchase is a
historically preferred option for some MVPD subscribers, an MVPD supplied MMI widget could execute
28
http://www.ietf.org/rfc/rfc2131.txt - DHCP
29
http://www.avahi.org/
30
http://www.zeroconf.org/
DSTAC WG4 Report
August 4, 2015
117
interactive bidirectional communication with the end user while keeping the user interface unified. The
MMI support widget is described at the end of this section.
Video content catalogs must be canonicalized for discovery via browsing, searching, and other possible
navigation mechanisms. Protocol-based approaches to this include, but are not limited to, Project Open
Data
31
(POD), Data Catalog Interoperability Protocol
32
(DCIP), and XML.
Service browsing could be performed using an HTTP GET on a given URL, which returns an XML
33
(eXtensible Markup Language) document formatted according to the conventions of RSS 2.0
34
(Really
Simple Syndication). Each content item is described using the format defined for the RSS 2.0 Media
Module
35
. This allows normal Web browsers to fetch the list, and aids in debugging and identifying
problems. The RSS protocol is widely used on the Internet to provide just this kind of information
(iTunes for example), and is supported by almost all Web browsers, as well as a large number of
specialized applications.
Service Information Metadata
There is no requirement today that cable MVPD’s provide additional metadata about service
information over CableCARD outside of channel identifiers and call sign
36
. Data about linear content that
may be available in the future (i.e., program guide information) is not provided, although it is part of the
CableCARD service information specification (SCTE 65 service information profiles 4-6).
To assure the accuracy of the presentation of programming data on competitive navigation devices, we
recommend the requirement of in-band or common-medium delivery of, at a minimum, basic
identifying programming data for all content types. This data could be optionally augmented on
competitive navigation devices, and it must be sufficient for effective user navigation when secondary
internet connectivity is not available. Basic metadata allows a device to still be navigable in one way
mode or in cases without network connectivity.
31
https://project-open-data.cio.gov/
32
http://spec.dataportals.org/
33
http://en.wikipedia.org/wiki/XML
34
http://www.rssboard.org/rss-specification
35
http://video.search.yahoo.com/mrss
36
December 12, 2002 Memorandum of Understanding Among Cable MSOs and Consumer Electronics
Manufacturers
DSTAC WG4 Report
August 4, 2015
118
Basic (Mandatory) Metadata includes:
● Channel identifier and call signs
● Show title and episode title
● Parental control information
● Start time and program length
● EIDR ID
37
for rich metadata retrieval
The ability for a service provider to provide enhanced metadata, such as descriptions, actors, and
graphics, must be an optional part of the delivery mechanism. An MVPD may choose to provide
enhanced metadata as a differentiator for their service. While linear channels should carry at least a
week of basic metadata in order to allow for scheduling, enhanced metadata must be provided for all
VoD and PPV assets to describe in detail what is available on a dynamic schedule. Manufacturers can
externally license guide and metadata to provide enhanced information based on knowing a linear
program’s title and episode number or EIDR ID.
Currently there are two standards available for use by MVPDs for service information metadata delivery,
SCTE65 binary tables and CEA-2033
38
xml data. SCTE65 service information profiles use a layered
approach to associate ‘event’ program ID’s with channel source ID’s. Each layer expands on the previous
to provide additional level of metadata. Service information profiles 4-6 relay program metadata
associated with a channel such as start times and length, show title, episode title, and show description.
ATSC
39
and DVB
40
compliant systems both use similar service information tables to provide up to two
weeks of detailed metadata, including episode descriptions. CEA-2033 is a much expanded and detailed
metadata system, containing all service metadata in one blob. Due to the nature of XML, each node can
be expanded to provide additional child nodes with service information, without modifying the protocol.
To satisfy MVPD evolution of service information metadata offerings, an XML based approach similar to
CEA-2033 might be the most extensible solution for the future. Any chosen solution should carry at least
the minimum required basic metadata described above.
Support Messaging / Man machine interface (MMI)
Upstream communication and the ability to run MVPD unique ‘apps’ has been one of the contested
areas of DSTAC. For example if an MVPD has a unique promotional offering (up-sell, weekend special
deal, etc) that isn’t defined in a standard Entitlement Interface, an interactive “widget” may be required.
Suggested here is a rich bi-directional interface to allow for service provider data and device information
to be relayed to the end user, along with providing a way to supply interactive widgets.
37
http://eidr.org - Entertainment Identifier Register
38
CEA-2033 - OpenEPG: A Specification for Electronic Program Guide Data Interchange
39
ATSC A/65:2013 - Program and System Information Protocol for Terrestrial Broadcast and Cable
40
ETSI EN 300 468 v1.4.1 - Digital Video Broadcasting; Specification for Service Information in DVB Systems
DSTAC WG4 Report
August 4, 2015
119
Currently CableCARD provides a Man Machine Interface (MMI), implemented by the MVPD. The
CableCARD MMI currently provides the following service:
● Status/information pages
● CCI information associated with a program being decoded
● Service information
● Notifications about program entitlements
● Notifications about device authentication issues
Proposed here is expanding the same MMI model to be far more robust. An expanded MMI with
bidirectional capabilities would be able to handle:
● HTML5 widgets to facilitate MVPD-unique consumer interactions
◦ support for javascript
● Display of widgets must be conditionally optional, based on user input, regulatory requirements,
and user actions
◦ For example, mandatory EAS messaging
● Allows for single API to interact with the DCAS and Provider Interface components
● DCAS can communicate privately to an MVPD component and respond
● Suitable for all communication with MVPD network “back office” components
● Billing, Upselling, and other unique entitlement interactions supported
The CableCARD MMI currently only supports a baseline HTML profile, which is its main limitation when
being used as a widget interface. Widget requirements would need analysis to determine the level of
HTML that the MMI should support. Hyperlinks inside an expanded MMI widget could support targets
on the greater internet to communicate directly with an MVD web service. Once defined, MVPD’s could
implement any bi-directional services desired that are supported by the protocol. This provides a secure
method for the MVPD’s to retain control over part of the user interface, while allowing for competitive
user interfaces to flourish. The MMI widget interface is not proposed or designed to replace an entire
UI, but to allow some interactive MVPD features to be available through an independent third party UI.
Features that would be suitable for such an MMI widget interface could be:
● Caller ID
● Sports statistics
● News ticker
Entitlement Information Interface
This interface provides the competitive navigation device information on the entitlement status of the
services described in the service discovery interface. It defines a common platform for publishing,
communicating, sharing and transferring rights information.
Entitlement implies some form of authentication of the device and/or user and/or household by the
Provider Interface. If the MVPD chooses to require that a consumer device be authenticated with the
Provider Interface before providing services, a consumer device can be identified through a standard
DSTAC WG4 Report
August 4, 2015
120
X.509 security certificate. This certificate would be issued by a common trusted authority, to prevent
requiring individual certificates for every MVPD DFAST currently operates similarly, where one single
certificate issued by a trusted authority allows a host to authenticate and then communicate securely
with the CableCARD.
The following scenario is an example of how a consumer device would obtain a certificate for
communication with the gateway:
● Each unique consumer device type has a certification number obtained after meeting
compliance requirements which is included on the device label, as well as a unique, per-device,
serial number.
◦ Compliance and testing regimes to be determined with industry feedback.
● The consumer browses to the MVPD certification site using their device, said site providing a
simple HTML-only page for device authentication.
● After validating the consumer service level and certification number, the MVPD generates a
certificate for the consumer device, which is then downloaded to the device where it is stored in
an appropriate local certificate store.
◦ Unidirectional systems would require obtaining the authentication certificate offline and
sideloading it into the system.
● The consumer device certificate would have a reasonably short expiration such as one month.
The consumer device would be responsible for requesting a new certificate some time before
the current one expires. This should be an automatic operation, whereby the device contacts a
standard MVPD URL, and the server responds with a new certificate if the consumer is still a
proper subscriber to the MVPD service. The renewal URL is contained within an extension field
in the certificate.
The certificate that the competitive navigation device must present to the Provider Interface is
described in RFC 5280. A good overview of these certificates and what they contain is described on
wikipedia
41
. The certificate shall be represented in DER format according to the ITU-T X.690 standard
42
.
The MVPD Interface only needs to verify that the certificate is valid, and signed by the appropriate
certificate authority. It is not desirable, nor possible, for this proposal to specify the exact procedures or
systems that an MVPD would use to manage certificate administration duties including certificate
revocation. It is expected that each MVPD will have unique operational requirements and needs.
An implementation of X.509 certificate handling that is in broad use today is the open source OpenSSL
[62] implementation. An MVPD might choose to delegate certificate provisioning to a third-party
certificate authority (CA) such as Verisign.
Content Delivery Interface
This interface delivers content to IP connected devices. It provides individual stream access for Live,
Linear, VOD, and network DVR content streams. It defines baseline requirements of the content formats
41
http://en.wikipedia.org/wiki/X.509
42
http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
DSTAC WG4 Report
August 4, 2015
121
(e.g. MPEG4), container formats (e.g. MPEG2) and stream protocols (e.g. HLS) to ensure interoperability
between the Provider Interface and the client devices. This Interface also defines the content protection
mechanism, and secure transfer of metadata such as entitlement and copy control information. As an
example of a content delivery interface, the DLNA media format model defines a set of required and
optional media formats for each of the three classes of media: image, audio, and video with audio.
Content Formats and Encoding
A service may provide streams in encodings not included in the basic set above to allow for future
formats. Obviously, a consumer device should not attempt to access a stream which it does not know
how to decode, and may choose simply to ignore them. Initially, only a small number of content formats
is needed, but more could be supported over time.
Container Formats
Media formats would be encapsulated in an MPEG2 Transport Stream (see ISO 13818) delivered over
HTTP. Video would be further encapsulated as MPEG2 or H.264 streams, limited to standard resolutions
and frame rates to be defined. A standard set of audio formats would also be defined. ATSC and SCTE
standards bodies already define such formats and could be used as reference. Compatibility with open
and interoperable formats currently in use by MVPDs today should be maintained where possible.
Adaptive streaming formats such as HLS or DASH could also be used. Video-on-demand services may
additionally provide support for the RTSP (Real Time Streaming Protocol) RFC 2326
43
. An extension
header is returned in the HTTP POST response for a VOD stream giving a URL on the gateway upon
which an RTSP session can be established. RTSP commands can then be given to cause the video data
being returned from the HTTP POST to pause, or to come from a different place in the program, and so
forth.
Stream Protocols
The on-demand services such as video-on-demand and network DVR should additionally support stream
control by the competitive user interface. The RTSP (Real-Time Streaming Protocol), HLS or DASH
protocols allow a consumer device to provide VCR-like control over the on-demand stream.
Content Protection
As noted in the WG2 report [45], MVPD content formats and CA/DRM systems vary. Sixteen different CA
schemes were presented, making interoperation with all of them a cumbersome task. The proposed
DCAS should terminate network CA/DRM and translate into an interoperable format similar to how
DFAST currently operates. DFAST is proof that converting various network encryption technologies into
a single common format works with varying CA systems throughout the country, across all cable
MVPD’s. Using this transcryption approach, legacy systems do not require replacement in field, the
DCAS and Provider Interfaces transcrypting operation handles this. Replacing legacy devices was a
concern stated by multiple MVPD’s, so this approach would allow for the easiest transition and could
43
http://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol
DSTAC WG4 Report
August 4, 2015
122
apply to newly deployed devices. Suitable content protection formats would be DTCP-IP, or subsequent
versions, for content sourced locally via a gateway. DTCP-IP transfers contains embedded copyright
control information receiving clients must abide by, this includes copy count for exporting recordings. In
the case of ‘cloud to ground’ delivery an approved secure digital output format such as Microsoft
Playready DRM would allow for interoperation with a wide variety of client devices..
Use Case Analysis
In this section the use cases from Section VII are analyzed with respect to the solution.
Tuning and Viewing a Linear Channel
Viewing linear television is a vital operation required by consumers. Due to the widely differing MVPD
architectures and delivery mechanisms, however, it is not straightforward to easily interoperate with all
of them. To solve this difficulty the MVPDs DCAS and Provider Interfaces terminate an MVPD's CA/DRM
and transcrypt to common output protocols. CableLabs DFAST is an excellent example of technology
offering such termination from differing MVPD CAS into one common security interface for third parties
to interoperate with. Cable industry already has one protocol, OCUR's DRI, that behaves similar to the
proposed Provider Interface. DRI abstracts all hardware details from clients and instead offers
operations like TuneChannel and Play, along with supporting trick modes over RTP. DTCP-IP is used as a
link protection protocol along with PlayReady DRM.
The Provider Interfaces would harmonize on IP outputs interoperation with third party consumer
devices across MVPDs. While some Cable operators would be able to implement the Provider Interfaces
directly from “Cloud to ground” as interfaces on their cable modems, some MVPD's due to their
architectural complexities or proprietary system issues might require an additional device in the home
that Provides the Interfaces for devices on the home network. Giving MVPDs options on how to
implement the Provider Interfaces while making them common across MVPDs is a way to reduce
complexities on all parties and keep the burden of implementation and licensing concerns minimal to a
third party.
In the case of DBS systems, where system complexities dealing with multiple satellites, transponders
and dynamically changing content locations a prosthetic serving the Provider Interfaces would provide a
canonicalized list of such content assets and deliver them through the common Content Delivery
Interface. SAT-IP is an example of such a system used in Europe. US-based DBS systems already provide
such gateway devices today delivering RUI with embedded video assets using RVU or a proprietary
system based on HTML5. Access to a canonicalized list of assets with associated rights is required to
interoperate with both of these gateway technologies and use them as a Provider Interface
embodiment, and this content list not a mandatory feature of either technology.
In the case of IPTV providers such as AT&T the DCAS and Provider Interface implementation would
provide termination of their proprietary DRM and channel change protocol, and transcryption to a
common Content Delivery Interface which is widely interoperable. Due to the IP/QAM based nature of
AT&T an additional device should not be required to implement the Provider Interfaces.
Since the DCAS and Provider Interfaces are implemented by each MVPD and knows their systems
limitations, they handle any concurrent stream management required by the IPTV network. Upon
exhausting of available streams signals can be sent to the consumer using the MMI. The MMI would
DSTAC WG4 Report
August 4, 2015
123
support signaling to deliver varying events to consumer devices. This signaling would deliver entitlement
information, EAS alerts, and copyright control information.
Linear television is looked at by this proposal as video only. Any ancillary data offerings and overlays
should be either delivered through the MMI or embedded in the program as an optional HTML5 widget.
Subscription features like caller ID display, sports statistics, et cetera, should use the MMI HTML5 widget
interface to reduce the burden of interoperation on the CE company.
Any client device with a decoder can support trick modes internally while obtaining data over IP. Server
devices with decoders can also offer trick play to clients as well with DLNA protocols and/or RTSP
operations.
Switched digital video is already abstracted away from retail cable set top box offerings using an
external tuning resolver which translates various MVPD implementations of SDV into a common
protocol. This tuning resolver is provided by the MVPD and runs internal software to convert the
different protocols of their own network into a common one. Communication with the tuning resolver
by a client device is handled using a binary protocol over USB to obtain tuning instructions. Tuning
resolvers require upstream communication with the headend, therefore they contain DOCSIS modems
which must be provisioned by the MVPD. Third party devices should not be required to include a DOCSIS
modem to support SDV. Tuning resolvers should continue to be external devices with defined protocols
or MVPD's must accept upstream communication originating from the general internet and agree upon
a unified cloud tuning resolver protocol. Because all of the Provider Interfaces are bi-directional
communication protocols using IP, no DOCSIS modem or other MVPD-specific network technology is
required. A unified and interoperable cloud tuning resolving protocol is the ideal software only solution
for third parties.
MVPDs can continue to support advertising features such as ad replacement by implementing them
within the DCAS and Provider Interface. The client end device receives a stream on the Content Delivery
Interface with the MVPD selected advertising already inserted into the stream. The proposed solution
places no restrictions on the evolution of ad insertion by the MVPDs. All requirements for acceptable
advertising, ad boundaries, ad lifecycle management, audience measurement, ad measurement and
reporting are supported because they are implemented by the MVPD in their DCAS and Provider
Interface implementation.
To support required operations like geo-filtering and geo-fencing, detailed metadata must be provided
by the MVPD along with sources of alternate content to display in place. Messaging about entitlement
rights and unauthorized channel redirection instructions should be signaled from the MMI to the client
upon access. The client device abides by all copyright controls and output restrictions as part of the
DTCP-IP protocol. Parental control can continue to be handled by presentation clients to satisfy legal
requirements (See “USE CASE #1 - Tuning and Viewing a Linear Channel”). Captions should continue to
be embedded in-stream or attached in the media container to assure synchronization and compliance
with appropriate rules and regulations (47 C.F.R. § 79.1 and 47 C.F.R. § 79.4).
Blackouts are replacement/unavailability of channel content specific to Television Market Areas (FCC
TMA’s) and/or Designated Market Areas (Nielsen DMA’s) based on operator contract. Enforcing
blackouts is a Provider Interface operation and should be part of service discovery. The MVPD has an
obligation to provide metadata for service discovery, this metadata should indicate a service is
unavailable or provide alternate sources of appropriate information. During blackout events the MVPDs
DSTAC WG4 Report
August 4, 2015
124
DCAS and other systems determines if a service is currently unavailable or replaced in the user’s market
and via the service discovery interface indicates either to the receiving devices. Both Dish and DirectTV
for example currently distribute gateway modules that already enforce these functions when providing
content to 3
rd
party devices.
On-Demand Content
On-Demand content catalogs contain lists of content assets, sometimes grouped by the MVPD or
content provider into categories. The Service Discovery Interface from the MVPD should at a minimum
provide:
1. a list of all titles available to the user
2. metadata on the titles including pricing information
3. a way to search the metadata across the on-demand catalog.
The MVPD may also include the category information which the competitive navigation device may
integrate into its unique user interface.
Some On-Demand services require confirmation of request for purchase. An HTML5 widget delivered
though the proposed MMI could support access to dynamic on-demand content. The bi-directional
communication with the MVPD could support transaction, subscription and free VOD. Since
communication would be directly with the MVPD an audit trail would be ensured. Features like Start
Over, and Look Back could be offered through the same widget. If VOD content is delivered as a playlist
pre-roll advertising could be inserted fluidly.
Pay Per View (PPV) events
PPV also requires verification of user intent to purchase. An HTML5 widget delivered through the bi-
directional MMI would allow for secure communication directly with the MVPD and could allow free
preview, purchase and cancellation windows, secure purchase credits and purchase limits. The Service
Discovery Interface would provide all required metadata on content available in the PPV service to
present to the user in the competitive user interface and enable the user to make a purchase decision.
Navigation
A competitive user interface is how third parties differentiate themselves today in the market place.
Offering a unique experience allows consumers choice in difference of presentation of content. This
proposal utilizes common defined protocols in the Provider Interfaces to communicate between the
MVPDs network and competitive navigation devices. These protocols separate data and control planes,
enabling an independent user interface. The data plane is described previously as the Service Discover
Interface, Content Delivery Interface, and Entitlement Information Interface. The control plane is where
navigation occurs and is orthogonal to security. A device would securely communicate with the data
plane, and then using its own choice of user interface technology present the list of content to a
consumer. There are currently no limitations on UI technology in CableCARD today and this outlet of
innovation must continue to exist as an option for independent third parties.
Devices should be allowed, dependent on copy control information, to securely record, copy and
transfer this content using approved digital outputs, no less than what CableLabs today allows through
CableCARD. The protocols CableCARD today offers allows PC applications to display content over the
network securely using DTCP-IP, while using a native app on the PC. The protocols abstract any network-
specific technology to a common protocol and the application deals with the data plane however it
DSTAC WG4 Report
August 4, 2015
125
requires. Tablet apps can be similarly implemented. Hauppauge
44
displayed an IPAD app during a WG2
presentation that utilized DLNA for discovery, DRI for tuner statistics, DTCP-IP for link protection during
delivery, along with a grid guide for navigation. Protocol based approaches lead the most flexibility and
implementation options for CE companies to innovate leading to unique features and devices.
Recording Linear Content
Recording content is a vital competitive navigation device feature that must continue to be allowed, if a
device manufacturer desires to include content storage such as a hard drive and where content rights
information permits. Hard drives should not be a requirement for recording implementations though,
cloud recording innovations allow for local and network DVR's. Recording to portable and/or RUI clients
could be accomplished by transcryption on the client device; currently in the CableCARD regime
CableLabs approves transcryption of DTCP-IP to Microsoft PlayReady for example.
Portable devices like tablets, phones, and laptops are an important part of an end users experience,
therefore recordings must be exportable to secure clients, either as copies from local storage in a
recording device or transfers of the recording. Microsoft Playready is a suggested DRM, where copyright
controls indicate protection is required, and allows for playback on most common portable devices
today.
Ninety minute timeshift/pause buffers shall continue to be allowed and minimally restricted for normal
use cases. Additionally, Copy Control information for a program, such as COPY NEVER, should not
restrict the ability to use a timeshift/pause buffer.
Remote Management by Consumer
By definition competitive navigation devices have their own differentiated remote management
systems. Managing MVPD related account settings could be proxied through to an MVPD's web service
on their customer website.
Set-Top Box set-up
By definition competitive navigation devices have their own differentiated set-up and configuration
wizards. These handle preferences, device settings, parental controls and accessibility.
Customer Support and Remote Management by Service Provider
The MMI allows the service provider to troubleshoot service delivery by messaging to the user if
communication is required.
Cloud Delivery
The source of content material does not matter when obtaining an asset list from the Service Discover
Interface. Material that originates in the cloud would be canonicalized and could be displayed through a
client devices RUI. Cloud delivery requires that an agreed upon protection scheme for cloud assets is
employed, such that the widest amount of interoperation is available. Microsoft PlayReady is already
deployed in many cloud to ground scenarios and is widely interoperable.
44
Brad Love presented for WG1 <FC docket #>{ref}
DSTAC WG4 Report
August 4, 2015
126
Closing and Summary
The proposed system is intended to secure content to the home and allow for the use of third-party
competitive user interfaces to display MVPD content. The proposal does not reach into policy issues
such as any requirements as to how MVPD content is presented to users. That particular issue is beyond
the mission of this working group.
As facilities-based MVPD services move to end-to-end IP transport of video data, the proposed system
can provide a “no hardware” solution to operator content availability on competitive navigation devices.
DOCSIS, ADSL, and wireless providers can leverage software supporting these protocols to provide on-
premises access (via WiFi or Ethernet) via competitive navigation devices. Other managed-medium
services (OSI Layer 1 and 2) may not support bidirectional DCAS authorization, key exchange, and
provisioning. Furthermore, some systems (such as satellite) may never provide a purely “hardware free”
solution to access of their primary unicast satellite transmission.
These legacy and one-way systems can make use of a Provider Interface Device or Gateway to provide
the same functionality as end-to-end systems on a local network. (Note: This requirement exists in both
protocol-based and remote-UI-based systems.) Currently-implemented examples of this modular
functionality include, but are not limited to, Dish Hopper, DirectTV Genie, SiliconDust HDHomeRun
(CableCARD to Ethernet), Hauppauge WinTV-DCR-2650 (CableCARD to USB), and the Simple.TV 2 (ATSC
to Ethernet).
By implementing DCAS and Provider Interfaces as described, users can enjoy client manufacturers’
alternative methods of navigating the remote UI services without losing any intended functionality. This
approach would provide a search capability, a launch capability and state management, with access to
same live, linear and VOD as MVPD applications.
DSTAC WG4 Report
August 4, 2015
127
Section II: “Application-Based Service with Operator Provided User-
Interface” System
Introduction
The apps approach developed in the marketplace through responses to consumer behavior and
preferences. As the apps model moved from the PC/Mac platform to smartphones, tablets, and other
mobile devices, it grew rapidly in just the last few years in adoption, popularity and major support from
MVPD and OTT app developers.
All of the major MVPDs now support an iOS and Android App to access their service on smart phones
and tablets. All of the major MVPDs support their service on Microsoft Windows and Apple Mac OS X
either through an application or a Web app (using a plug-in model for content protection today and
transitioning to an HTML5 EME Web App in the future). Some of the major MVPDs already support
Smart TVs (LG, Samsung, Sony, Toshiba), game consoles (PlayStation 3 & 4, Xbox 360 & One), and set-
top boxes (Roku). Table 1 summarizes the supported retail devices, and MVPDs are also devising still
more ways to expand the range of devices and platforms that can support MVPD apps. VidiPath
Certification was launched in September 2014, and certified VidiPath client devices are expected in the
market later in 2015. Many of the major MVPDs either support DLNA VidiPath today or plan to in the
near future. ABI is projecting that VidiPath Certified devices will be available in approximately 40
percent of all U.S. cable households that subscribe to advanced services by 2016, and 70 percent by
2020. RVU, developed and maintained by the RVU Alliance (and included in DLNA guidelines), is
supported by DirecTV, developed and maintained by the RVU Alliance, is supported by DirecTV. And
MVPDs are continuing to expand their support for more devices and platforms.
MVPD apps follow the same approach as the apps that Netflix, Amazon, Hulu, Google, YouTube and
other OTT providers use for delivering service on retail devices and platforms. The apps approach
abstracts the differences between varied and rapidly changing consumer electronics platforms and
varied and rapidly changing multichannel services that has evolved far beyond the simple broadcast
video service on which CableCARD was based.
MVPD apps are by far the most widespread method for delivering service to retail devices and platforms
today. Compared with the fewer than one million retail CableCARD devices today, there have been over
56 million downloads of MVPD apps as of July 23, 2015, with millions more occurring every month.
Roku, a retail set-top box that relies entirely on apps (including a cable operator app with a cable-
operator supplied guide), has sold over 5 million units, outselling TiVo (with its “third party” TiVo guide)
five-to-one.
As shown above in Table 8, there are over 450 million retail video devices in the US that can be served
by an MVPD app—about twice the number of set-top boxes in use by MVPDs. 94% of them can be
served by one or more MVPD apps. 66% can be served by an app from all of the top 10 MVPDs.
The specifics of how MVPDs deliver their service to PCs and MACs (either as a Web or as an app
written to the PC or MAC operating system), as well as the number of subscribers for each MVPD is
shown in Table 9.
DSTAC WG4 Report
August 4, 2015
128
MVPD
Subs (M)
45
PC (Windows/Mac OS X)
46
Comcast
22.6
Web app
DirecTV
20.3
Web app
DISH
14.1
Web app (DishAnywhere.com) and Native app (Slingplayer App)
TWC
11.4
Web app
AT&T U-verse
5.7
Web app
Verizon
5.3
Web app
Charter
4.4
Web app
Cox
4.3
Native app (Cox TV Connect)
Cablevision
2.7
Native app (Optimum)
Table 9 - MVPD Subscriber Count and Support for Personal Computers
This Apps-based System proposal leverages this technological advancement and the development work
in Internet (W3C) HTML5, iOS, and Android; the cross-industry standards developed in DLNA and RVU
for interoperability among MVPD and retail devices; and current efforts for implementing HTML5 apps
to reach additional retail devices.
By utilizing the most widespread approaches employed by MVPDs and OTT providers, and software
components widely adopted by CE manufacturers, this proposal enables retail device manufacturers
many choices for how to receive MVPD services. In this System, the retail device manufacturer can
choose one or more of the following techniques to build a retail device that can provide the MVPD
service through a downloaded MVPD app or MVPD RUI:
Device Specific Apps (e.g. iOS, Android, Samsung Smart TV, LG, Xbox, PlayStation, Roku)
HTML5 Web Apps
DLNA VidiPath
RVU
DISH Virtual Joey
Sling Media Technology Clients
The MVPD or OTT video provider can use a common cloud infrastructure to deliver content in an
optimal fashion to the broad diversity of retail devices and platforms using one or more of these six app-
based approaches. Device Specific Apps can take advantage of the latest features in the latest devices
and tailor the user experience to the specific device, e.g. multi-touch, accelerometers, finger print
identification, and speech recognition. Web Apps executing on a standard HTML5 platform can reach a
broad set of devices with a rich set of application features. DLNA VidiPath leverages the W3C HTML5
45
SNL Kagan
46
Either as a browser plug-in or as a Windows & Mac OS X application (in the future HTML5 EME/MSE
will deprecate browser plug-ins)
DSTAC WG4 Report
August 4, 2015
129
Web App model, but also integrates with other devices on the home network offering a rich home user
experience.
There is a high degree of commonality across all six app approaches:
- IP video transport to the end device
- IP-based DRMs for content protection
- A rich, competitive, omnipresent CE user interface shell controlling the device
- Multiple, competitive, app-based MVPD and OTT video service user interfaces
- CE services are enhanced and updated by updating the platform
- MVPD and OTT services are enhanced and updated by updating the applications
Because of these commonalities, retail devices can also implement multiple approaches to
accommodate multiple MVPD approaches rather than just a single approach. For example, VidiPath,
HTML5, and Sling are all HTML5-based. One integrator (Jethead) has implemented both VidiPath and
RVU in a single smart TV stack, as was shown at the 2015 INTX Conference.
Error! Reference source not found. shows this approach as each MVPD or OTT video provider hosts a
set of cloud services and provides an app for the relevant app platforms (Android, iOS, Windows, OS X,
game consoles, etc.). Content is protected using the DRM used on the respective platforms and the
corresponding hardware.
Figure 38 - Overview of App Approach
Collectively, this System abstracts the diversity and complexity of service providers’ access network
technologies and customer-owned IP devices and accommodates rapid change and innovation by both
service providers and consumer electronics manufacturers. This application approach may also make
use of a combination of software-downloadable security and (when available) a hardware root of trust,
as described in [WG3], and may utilize the application to enforce other limitations on access, copying,
distribution, and usage in a similar way to how they are currently enforced through leased MVPD device
applications (such as blackouts, geo-filtering and geo-fencing, alternate content, messaging and
Ne lix
Cloud
Services
Ne lix
App
CA/DRM:
Cloud:
Applica on:
Pla orm:
Adobe
Access
Microso
PlayReady
Google
Widevine
OMA
Cisco
VideoGuard
Verimatrix
VCAS
ARRIS
SecureMedia
NAGRA
anyCAST
YouTube
Cloud
Services
YouTube
App
Amazon
Cloud
Services
Amazon
App
Hulu
Cloud
Services
Hulu
App
AT&T
Cloud
Services
AT&T
App
Cablevision
Cloud
Services
Cablevision
App
Charter
Cloud
Services
Charter
App
Comcast
Cloud
Services
Comcast
App
DIRECTV
Cloud
Services
DIRECTV
App
Apple
FairPlay
…
…
SlingTV
Cloud
Services
SlingTV
App
…
DTLA
DTCP-IP
Android
iOS
Windows
OSX
AndroidTV
FirefoxOS
Tizen
WebOS
…
PlaySta on
XBOX
AMD ARM
Broadcom
OMS
Marvell
…
MStar NXP
Sigma
ST
Intel
Hardware:
DSTAC WG4 Report
August 4, 2015
130
redirection for unauthorized channels, and parental control) and not exclusively through the security
system. This diversity and flexibility enables the broadest coverage of retail devices, optimizes the
consumer experience on the latest devices and technologies, and takes advantage of a wide range of
market-tested security measures including downloadable DRMs.
The following sections discuss these app approaches.
Device Specific Apps
Today almost all of the relevant retail devices provide an app platform (e.g. iOS, Android, Samsung
Smart TV & Tizen, LG WebOS, Xbox, PlayStation, Roku, TiVo, etc.) with an associated Software Developer
Kit (SDK) that includes the platform APIs, developer’s program, and app store to enable apps to be
downloaded to their devices. These app platforms either provide access to one or more embedded
platform DRMs and/or allow for an app developer to provide a DRM of their own choosing integrated
into their app. The robustness of the various DRM implementations, embedded or integrated with app,
varies and will impact the quality of the content that can be displayed on the device subject to content
license requirements. In order to support their App marketplace these platforms have developed
various security capabilities to insure that the content and applications are protected appropriately.
While these app platforms all provide an app developer program with an associated SDK and app store,
they differ in the specifics of the licensing involved, the app development process, and the app approval
process. These differences reflect a competitive marketplace where device manufacturers attempt to
provide the best app development platform and device volume to encourage the development of
compelling applications that will attract consumers further increasing the value of their products. These
differences in the respective app ecosystems also reflect the diversity of device capabilities (e.g. smart
TVs versus smart phones versus game consoles) provided by the platforms. The device manufacture
chooses its own app platform and provides a set of app guidelines with an app approval process that is
defined and managed by the platform developer. These guidelines and app approval processes control
what apps make it on to their platform via distribution in their app store.
In developing apps for different app platforms, MVPDs are no different from any other app developer.
They participate in the app platform just as any other app developer for that platform. MVPDs take into
consideration the same factors as any other app developer when deciding which platforms to use,
platform capabilities, reach, ease of development, device popularity, license terms, etc.
App Development
App Developer programs
The app developer program is intended make it easy for app developers to develop applications. The
better programs provide extensive documentation of their SDK, example code, as well as development
tools, such as Integrated Development Environments (IDE) and device emulators. Some of these
platforms use HTML5 and JavaScript as the platform, while others provide scripting languages, and still
others develop in Java or other programming languages. This also provides another point of
DSTAC WG4 Report
August 4, 2015
131
differentiation. Devices that support these platforms can expose various resources of the device to app
developers, such as multi-touch and speech recognition.
Platform
Description
iOS
Apple’s developer program iOS and Mac OSX is available at:
https://developer.apple.com/programs/ and provides extensive documentation and
resources for application developers. Xcode is Apple’s integrated development
environment (IDE). Xcode includes a source editor, a graphical user interface editor, and
many other features. Apple provides an iOS Simulator that simulates multiple iOS and
watchOS environments.
Android
Google’s Android developer program is available at:
http://developer.android.com/index.html and provides extensive documentation and
development resources for application developers. There are two integrated application
development environments (IDEs) available for Android, Eclipse or Android Studio with
Java as the development language. The Android SDK includes a mobile device emulator.
Samsung
Smart TV &
Tizen
Samsung supports two app developer programs for its smart TVs with its Smart TV
platform or its Tizen platform. The Samsung developer program is available at:
http://www.samsungdforum.com/ and provides extensive documentation and support.
Samsung is in the process of phasing out the Smart TV platform in favor of the Tizen
platform. The Smart TV platform supports Web applications, while Tizen supports Web
applications, native applications and hybrid applications. However, Samsung Tizen TV
provides only a Web application environment for app developers. App developers in
Tizen also develop applications based on Web technology (HTML5, CSS3, Javascript).
Tizen also supports Samsung’s mobile devices, tablets, smart phones, and smart watches.
LG webOS
LG’s webOS developer program is available at: http://developer.lge.com/webOSTV/ and
provides documentation and support. LG uses the Eclipse IDE for development. LG
provides a webOS TV Emulator that emulates webOS TV on a computer enabling the
developer to test and debug apps on a computer.
Roku
Roku’s developer program is available at: https://www.roku.com/developer and provides
documentation and support. Applications on the Roku player are developed in
BrightScript, a scripting language, using an Eclipse IDE.
Table 10 - App Developer Programs
DSTAC WG4 Report
August 4, 2015
132
Supported DRMs
The app platforms also support different DRMs. Platforms with a broader set of DRMs potentially
support content from more sources.
Platform
Supported DRMs
iOS
FairPlay and third-party DRMs such as Video Guard
Android
Any, provides a DRM framework supporting third-party DRMs as plug-ins
Samsung Smart TV
& Tizen
PlayReady, Widevine, Verimatrix, SecureMedia, SDRM, and SCSA
LG WebOS
PlayReady, Widevine, Verimatrix
Roku
PlayReady for Smooth Streaming and AES-128 bit encryption for HLS
Table 11 - Platform Supported DRMs
App Guidelines
App platforms also differ in the guidelines they provide to app developers to provide the criteria by
which applications are evaluated in the app review process. Some provide very explicit and
comprehensive guidelines that are strictly adhered to and others provide looser guidelines with less
strict enforcement. In general, these guidelines are living documents and subject to revision over time.
Platform
Description
iOS
The Apple app guidelines can be found at:
https://developer.apple.com/app-store/review/guidelines/
Applications for the iTunes Store are developed, tested, and distributed
using guidelines and tools that Apple provides to all developers. Apple
regulates applications and their functionality by enforcing a testing
process that occurs upon submission of an app to the iTunes Store. While
there is no guaranteed maximum duration of this process, Apple tries to
review all submitted applications within a week. During this time, their
testers evaluate the app against a strict set of requirements which
ensures that the submitted applications perform as desired on selected
platforms, do not violate any of Apple’s terms and conditions, and do not
provide an outlet for any illegal activity.
Android
The Android App ecosystem is not as stringently managed as the Apple
iOS app ecosystem. Android apps are not strictly approved by Google and
are self-signed only. Apps can be delivered from the Google Play Store
over Google protocols, or the Amazon Fire Store, or they can be side-
DSTAC WG4 Report
August 4, 2015
133
Platform
Description
loaded directly onto the device. Google provides a set of developer
guidelines to assist in the development of Android apps, as well as a set of
design guidelines that help developers to make apps that not only work
well but also look good. The developer guidelines for Google Play can be
found at: http://developer.android.com/distribute/tools/launch-
checklist.html#understand-policies
Samsung Smart TV
& Tizen
In order to distribute applications on Samsung TVs and make them
available through the Samsung Smart Hub Apps TV store, it is necessary
to register the application and it must go through a certification process
provided by Samsung or its Affiliate at the Application Seller Office before
being launched on the Samsung Apps TV store. To request certification, it
is necessary to prepare the Tizen widget package and metadata and
submit it in the Samsung Apps TV Seller Office
LG WebOS
The LG application quality assurance team evaluates the performance,
function, and UIs of submitted apps to verify the suitability for publishing
on LG Content Store (LG STORE). Valid apps are published on LG Content
Store (LG STORE). Every app submitted to LG Smart World will go through
a Quality Assurance (QA) process before sale is permitted. Those Apps
that do not meet the QA criteria can be rejected for sale. The QA criteria
applies to every app submitted but certain Apps such as game, video,
education, etc, can be subjected to additional criteria by category.
Roku
Roku television design guidelines can be found at:
http://sdkdocs.roku.com/display/sdkdoc/Design+Guidelines. The specific
restrictions and terms for publishing content to the Roku Channel Store
are found in the Roku Developer Agreement.
Table 12 - App Development Guidelines
Operation of the App
The functionalities comprising the MVPD service, including a user interface, are provided via the
application operating on the device. The MVPD service is enhanced and updated by updating the
application. The interface between the MVPD app and the device is provided through the device
manufacturer’s platform SDK. The interface between the MVPD app and the DRM is either provided as
part of the platform SDK or is the one selected by the MVPD and built into its app. Figure 39 shows
examples of these two models. In the case of Device 1, the platform provides an embedded DRM client
(DRM A). In the case of Device 2, the DRM client is integrated into the MVPD’s app. The MVPD then
operates a DRM server for each DRM used, one for DRM A and one for DRM B, and the MVPD service is
provided using either DRM.
DSTAC WG4 Report
August 4, 2015
134
Figure 39 - Example App Interfaces
The essential downloadable security component is the DRM client, that is downloaded and updated
either as part of the operating system of the platform on Device 1 or as part of the MVPD application on
Device 2. The DRM control plane and the secure video content data plane are identified in this diagram.
Information
The device specific platforms include:
Apple iOS - https://developer.apple.com/programs/
Android - http://developer.android.com/index.html
Samsung Smart TV & Tizen - http://www.samsungdforum.com/
LG WebOS - http://developer.lge.com/webOSTV/
Microsoft Xbox - http://www.xbox.com/en-US/developers
Sony PlayStation - https://www.playstation.com/en-us/develop/
Roku - https://www.roku.com/developer
Applicable Devices
As outlined above Apps can be developed for almost every class of retail device, including:
Smart or connected TVs
Game Consoles
Retail set-top boxes or HDMI sticks
MVPDApp
OS1
DRM:
Cloud:
Applica on:
Hardware:
Applica on:
Device1
Cloud
Services
DRMA
License
Server
Adap ve
Bit-Rate
Server
MVPDApp
DRMA
Client
DRMB
License
Server
WebServices
Device2
DRMB
Client
OS2
OS:
ControlPlane ControlPlane
DataPlane Dat aPlane
DSTAC WG4 Report
August 4, 2015
135
Personal computers (both Windows and Mac)
Tablets
Smart phones
HTML5 Web Apps
MVPD Web apps make use of the W3C HTML5 standards to reach retail devices. This includes personal
computers (both Windows and Mac OS based), as well as other retail devices that implement the W3C
HTML5 standards. The interface between the MVPD Web apps and the secure video player are defined
by the HTML5 Media elements, Media Source Extensions (MSE) [57] and Encrypted Media Extensions
(EME) [58], which are the W3C specifications for processing multi-media, including protected
audio/video content, exposed through JavaScript APIs.
As in the case of the device specific apps, the functionalities comprising the MVPD service, including
those features and functionalities expressed via a remote user interface, are provided via the application
operating on the device. The MVPD service is enhanced and updated by updating the application.
HTML5 Media elements are used to present video and/or audio data to the user. HTML5 media
resources can have multiple audio, video and data tracks. HTML5 includes standard definitions for
special media tracks, including alternative media, captions, descriptive audio, sign language, subtitles,
translation and commentary.
The Media Source Extensions (MSE) specification [57] defines an API that a web page can use to feed
media data to the HTML5 video or audio element. This API enables JavaScript in the page to:
Handle processing of an adaptive media manifest file.
Fetch the media segments using the URL from the manifest file
Append the media segments for playback by the platform’s media player.
The MSE API can be used for insertion of other content like advertisements, alternative media or
playback of a local media file.
The MSE API enables JavaScript to send byte streams to the various media codecs implemented in
HTML5 platforms. This allows the prefetching and buffering of media streams to be implemented in
JavaScript providing greater flexibility and application control over these media streams. This flexibility
allows the application to optimize the playback of media from multiple sources.
Encrypted Media Extensions (EME) [58] is the W3C specification that defines the APIs necessary to
control the playback of protected content. The EME specification [58] specifies a JavaScript API that a
Web app can use to playback content, securely protected by any EME-compliant DRM system, using the
HTML5 Video or Audio element. The API enables the page to:
Detect attempted playback of protected content.
Learn what DRMs may be used to playback the content.
Request the appropriate DRM license needed for content playback.
DSTAC WG4 Report
August 4, 2015
136
Provide DRM licenses to the user agent for content decoding.
A platform supporting EME may implement any number of DRM-specific content decryption modules
(CDM) that handle license processing and content decryption. EME does not specify any particular
content encryption nor any set of DRMs, nor does it define how a CDM is implemented (including
installation, updating or revocation) in the platform. EME does require support for the Clear Key [61]
decryption so that platform EME implementations can be tested or used without a commercial DRM.
As in the case of device specific apps, the robustness of the DRM implementations embedded into the
HTML5/EME platform varies and will impact the quality of the content that can be displayed on the
device subject to content license requirements. Some HTML5/EME implementations allow for multiple
or alternative DRMs to be selected by the HTML5 application. Figure 40 shows two examples of the
HTML5/EME implementation. In the case of Device 1, the platform provides access to an embedded
DRM client (DRM A) integrated into the underlying OS and hardware root of trust. In the case of Device
2, the software DRM client is integrated into the HTML5 software platform and not integrated into the
underlying OS and hardware root of trust. The MVPD then operates a DRM server for each DRM used,
one for DRM A and one for DRM B. It also shows how through the use of common encryption and DASH
transport one set of video files can be decrypted and displayed through different DRMs. The DRM
control plane and the secure video content data plane are identified in this diagram. Note that due to
content license requirements, since the embedded DRM A is integrated into a hardware root of trust,
Device 1 may be able to decrypt and display a higher quality of video than enabled by the software DRM
B client in Device 2.
DSTAC WG4 Report
August 4, 2015
137
Figure 40 - HTML5/EME Implementation
World Wide Web Consortium (W3C) Specifications
The W3C Specifications are publicly available at: http://www.w3.org/TR/. The following W3C Standards
are relevant to enabling competitive availability of devices that receive MVPD services:
HTML5 - A vocabulary and associated APIs for HTML and XHTML, W3C Recommendation, World
Wide Web Consortium, http://www.w3.org/TR/html5/ [39]
W3C MSE, Media Source Extensions. http://www.w3.org/TR/media-source/ [57]
W3C EME, Encrypted Media Extensions. http://www.w3.org/TR/encrypted-media/ [58]
W3C Crypto, Web Cryptography API. http://www.w3.org/TR/WebCryptoAPI/ [61]
Protocols
The protocols used include:
TCP/IP https://tools.ietf.org/html/rfc793
HTTP, HTTPS https://tools.ietf.org/html/rfc7230
MPEG DASH [40]
MPEG CENC
.
DRM:
Cloud:
Pla orm:
OS/Hardwar e :
Applica on:
HTML5
Device1
Cloud
Services
DRMA
License
Server
ISO
Common
Encryp on
DASH
EME
DRMA
Client
CDM
DRMB
License
Server
HTML5 EME
CDM
Media
WebApp
Media
WebApp
Device2
DRMB
Client
One set of video files
is decoded by
different DRMs in
different browsers.
ControlPlane ControlPlane
DataPlane DataPlane
DSTAC WG4 Report
August 4, 2015
138
Applicable Devices
HTML5 with EME and MSE is applicable to any device that implements these standards including:
smart/connected TVs, set-top boxes, game consoles, PCs, tablets, and smart phones.
DLNA VidiPath™
DLNA VidiPath defines a set of guidelines for accessing protected media services from a device in the
home network a Remote User Interface (RUI). VidiPath enables MVPDs and OTTs to deliver their service
to DLNA-certified retail devices by using an HTML5 Web app. VidiPath enables video services to be
delivered via a home server model and/or via a cloud to ground model. DLNA VidiPath adopted HTML5
for its Remote User Interface (RUI) functionality and thus uses the same APIs described in the HTML5
Web Apps section above, including MSE, EME and WebCrypto. DLNA VidiPath also makes use of DTCP-
IP link-layer protection for the transmission of content over the home network. DLNA adds the ability to
discover digital media servers (DMS) on the home network and access content on them. As is the case
for device specific apps and HTML5, the functionalities comprising the MVPD service, including those
expressed via a remote user interface, are provided via the application operating on the device. The
MVPD service is enhanced and updated by updating the application.
CableLabs, in partnership with industry participants such as Intel and ARM, has developed open source
implementations of VidiPath Server and Client [55]. These implementations are aligned with libraries
used by Reference Device Kit (RDK), an integrated software platform initiative for MVPD customer
premise equipment (CPE) led by major MVPDs in the U.S. and Europe [56].
The VidiPath specifications enable consumers to consume premium subscription TV content on devices
of their choice with a consistent user experience across all devices. Using VidiPath HTML5 RUI, service
providers are able to enhance their Web application in the cloud (just like any other Web based
company) and evolve their services more rapidly, thus reducing time-to-market for new services and
products features. The auto service discovery feature supported by VidiPath facilitates easy installation
and setup, which is a benefit to both consumers and service providers.
The Diagnostics feature allows service providers to remotely diagnose and troubleshoot any service
related issues.
VidiPath authentication provides assurance to service providers and content providers that only certified
VidiPath devices access their services and provides assurance for their user experience on retail devices.
VidiPath offers a single, interoperable solution to retail device manufacturers to enable premium
subscription TV services from different service providers.
Standards
DLNA Guidelines, http://www.dlna.org/dlna-for-industry/technical-overview/guidelines [60]
Protocols
The protocols used include:
UPnP
DSTAC WG4 Report
August 4, 2015
139
TCP/IP
HTTP
HTTPS
MPEG DASH [40]
DTCP-IP
Information
The DLNA VidiPath Guidelines can be obtained at: http://www.dlna.org/dlna-for-industry/technical-
overview/guidelines
Applicable Devices
Any DLNA VidiPath certified device including: smart/connected TVs, set-top boxes, game consoles, PCs,
tablets, and smart phones.
RVU™
The RVU protocol addresses the digital video industry’s need for commonality and flexibility. See
“RVU™”.
Information
The Version 1.0 RVU Specification has been publically available since Fall 2009, Version 2.0 since
Fall 2012, and a comprehensive certification program has been in place since Spring 2011. RVU
is implemented on a wide variety of technology platforms, and has won awards at major trade
shows and conferences around the world. RVU devices have been fielded to consumers
nationwide since Fall 2012, in the form of 9 million DIRECTV Genie branded servers and several
times the number of servers in Genie branded clients as well as RVU-certified Smart TVs from
Samsung, Sony, LG and Toshiba. 4K/UHD services became available on RVU servers and Smart
TVs from Samsung during 4Q/2014.
Virtual Joey
DISH Network provides and supports a number of in-home devices for its subscribers to enable
reception and navigation of its service. These include the Hopper® Whole-Home HD DVR and the Joey,
which enables Hopper DVR features in every room. Additionally, DISH supports the Virtual Joey client
software on Sony PS3™ and PS4™ systems. A virtual Joey is authenticated during connection to the
associated Hopper, which allows the Hopper to rely on additional robustness and other security
features. The Virtual Joey behaves like a (real) Joey client, and enables navigation of DISH’s broadcast
system and Hopper DVR recordings.
Standards
The Virtual Joey is built on home network standards, including Ethernet and WiFi; UPnP device
discovery; DLNA media streaming (and proprietary extensions); DTCP-IP content protection; and
HTML5. Virtual Joeys are co-developed among DISH, EchoStar, and a device manufacturer pursuant to
negotiated business terms.
DSTAC WG4 Report
August 4, 2015
140
Protocols
HTML 5 for RUI, TLS certificate processing; IP
Information
See http://www.dish.com/virtual-joey/
Applicable Devices
Playstation®3 and PlayStation® 4 systems
Sling Media Technology Clients
DISH Network provides and supports the Hopper® with Sling® Whole-Home HD DVR. DISH also supports
the Sling Adapter connected to its Hopper, ViP 722, or ViP 722k DVR receivers. DIRECTV similarly offers a
GenieGo device, which connects via the home network to its HD DVR receivers. The ARRIS MS4000
(Media Streamer 4000) enables MSOs to use the same technology to serve their customers.
Standards
Ethernet; 802.11n WiFi. SlingBox clients are co-developed between EchoStar and a device manufacturer
pursuant to negotiated business terms, or by EchoStar on platforms that support independent
development environments.
Protocols
IP
Information
DISH or MSO subscribers load the applicable Slingplayer App on their chosen retail device, which can
then watch and navigate live or recorded TV and access program guide and DVR content, and operate
other features of the related service.
Applicable Devices
ARRIS MS4000 (Media Streamer 4000); DISH Hopper, ViP 722; ViP 722k; Mac or Windows PC; iOS,
Windows, Amazon Fire and Android tablets and phones; Apple TV; Roku or Roku TV; Google
Chromecast; Amazon Fire TV.
Use Cases Supported
Unlike the CableCARD/UDCP model, which was designed for reception of linear cable channels from
digital cable systems for reception on cable-specific UDCP devices, applications as an approach are
platform and technology neutral, allowing retail devices to operate across MVPD and OTT platforms,
and support linear, on-demand, interactive, and other advanced features of the MVPD service, while
respecting the usage limitations associated with licensed copyrighted content. See “Essential Customer
Experiences”; and Report of WG1, MVPD Requirements and Content Providers Requirements [76].
Tuning and Viewing a Linear Channel
The apps models abstract the transmission methods for the MVPD’s network and deliver the service in
IP, using the audio and video codecs and the picture resolutions and formats supported by the retail
device. The robustness and capabilities of the App platform may affect what content is available to
devices that are supported by the App platform. The application also handles any concurrent stream
management required by the network or content agreements. The application supports any applicable
switched digital video.
DSTAC WG4 Report
August 4, 2015
141
The application tunes the channel and presents integrated applications associated with the tuned
channel, such as camera angles, as well as subscription applications such as sports statistics, interactive
advertising, and caller ID on TV.
The application also presents the broadcast, zoned or targeted advertising inserted into the linear
channel. Interactive request for information and telescoping ads are supported. All requirements for
acceptable advertising, ad boundaries, ad lifecycle management, audience measurement, ad
measurement and reporting are supported.
The application supports blackouts, geo-filtering and geo-fencing, alternate content, messaging and
redirection for unauthorized channels, and parental control. The application manages copy controls and
output restrictions.
The application supports trick play capability.
The application supports the network’s technology to reduce channel change latency.
The application supports all regulatory requirements, including delivery of EAS and statutory
privacy requirements.
On-Demand Content
In addition to supporting linear content and features, applications support transaction, subscription, and
free VOD; EST; Start Over and Look Back. They also meet advertising requirements as required by
content providers who license the content and advertisers who fund the dual-revenue MVPD business,
e.g., dynamically inserting pre-roll advertising or disabling fast forward during advertisements included
with VOD content. In addition, applications support limitations on in-home and out-of-home viewing,
and limitations on simultaneous viewing e.g. across a viewer’s authorized devices.
Pay Per View (PPV) events
Applications also support PPV requirements such as free preview, purchase and cancellation
windows, secure purchase credits and purchase limits.
Navigation
Apps use a UI designed by the MVPD for interacting with the MVPD’s experience. Consumers
receive a common, familiar MVPD experience across devices, such as the ability to navigate and see
recent tuning history regardless of which device was used. This is similar to how consumers experience
Netflix and other OTT video services. Retail devices that host the application may continue to
differentiate themselves with features, functions, networks, drives, speed, look, feel and price, and may
have their own top level user interface, app store, and menu structure. This is consistent with the
approach used by OTT video providers and with public pronouncements by Thomas Riedl, head of
Google’s Android TV, “Content owners and distributors are one of the key stakeholders for us. For them,
what’s crucial is they want to deliver the best user experience and make sure that the content they
provide to the user is displayed exactly as they broadcast it. Also in their role as app developer, they need
to be able to completely control the experience. Android TV allows them to do all of these things based
on our proven technology platform.” IPTV News 4/21/15, http://www.iptv-news.com/2015/04/google-
google-tv-has-evolved-into-android-tv/.
DSTAC WG4 Report
August 4, 2015
142
Apps present the modern features of MVPD navigation, such as mosaics, recommendations
from what’s trending or popular in the neighborhood, view by genre, and recommendations from a user
profile across devices. DLNA VidiPath and RVU offer the ability to navigate to and discover content or
services on the home network.
Apps enforce content license requirements from content providers, including channel
presentation in required neighborhoods (e.g., news channels) and channel assignments (e.g.,
broadcaster carriage on channel); channel logos; and search requirements (such as a network-branded
point of entry). There is no standard feature for a retail device to conduct deep search from outside of
the MVPD app. YouTube previously provided an API that permitted DIRECTV and other third parties to
deep link to and play YouTube content without seeing the YouTube UI; it subsequently removed that API
and substituted a new API through which the YouTube UI presents YouTube content, even when
accessed from a link.
47
Facebook and Twitter apps do not automatically enable deep search by web
browsers. However, marketplace search deals can be done by mutual agreement, as Twitter agreed to
do with Google and Netflix agreed to do with TiVo. Requiring negotiation is an established means for
assuring that the “search” does not artificially raise or suppress rankings in search results. There are also
opportunities for business-to-business deals for new user interfaces. For example, Xbox One uses a UI
that was designed to be familiar to TWC subscribers and to Xbox users. It also integrates MSFT connect
voice and gesture control. Likewise, TWC built a grid guide for Roku.
Recording Linear Content
The DLNA VidiPath spec provides a recordable DTCP-IP output, so that a retail DVR can record
programming received by VidiPath. RVU servers similarly provide a recordable output, with copy control
information set in accordance with content agreements. DLNA continues to evolve, and may augment
this in the future.
Content providers generally do not currently permit apps on mobile devices to provide a
recordable output. Similarly, Netflix does not present a recordable output to CE devices. Apps to Smart
TVs may present recordable outputs. Content providers licensing terms may continue to evolve, and
downloadable Apps/DRMs can be updated accordingly.
47
Under Google terms of service, Google also demanded that Microsoft shut down its use of YouTube because
"The app blocked ads on videos, and it allowed users to download videos directly to their devices. Additionally,
Google has said that the app also violates another rule, because it allows users to watch videos that have been set
by the publisher to only play on certain devices (ie. some videos are blocked on mobile.)"
As predicted: Google asks Microsoft to shut down new YouTube app
http://www.phonearena.com/news/As-predicted-Google-asks-Microsoft-to-shut-down-new-YouTube-
app_id43091 The Google YouTube Developer agreement now includes requirements that the developer protect
Google’s brand and not "separate, isolate, or modify the audio or video components of any YouTube audiovisual
content made available through the YouTube API." https://developers.google.com/youtube/terms?hl=en
Netflix likewise terminated its public API. Gigaom: Netflix is shutting down its public API today
https://gigaom.com/2014/11/14/netflix-is-shutting-down-its-public-api-today/. We have not found any evidence
of a public API through which Amazon permits third party sites to play Amazon Prime Video outside of the Amazon
experience.
DSTAC WG4 Report
August 4, 2015
143
Remote Management by Consumer
Apps for the Smart TV and other devices enable consumers to change channels and manage
their account via a network-connected mobile device. Such apps also allow consumers to manage their
caption settings and other accessibility features and select their language through the mobile device.
Set-Top Box set-up
Apps for the Smart TV support establishing menu preferences, device settings, parental controls
and accessibility.
Customer Support and Remote Management by Service Provider
Apps permit the service provider to troubleshoot and support device experiences.
As a common cross-platform MVPD experience is delivered across all retail devices via the
MVPD App, MVPDs are able to offer better and consistent support and diagnostics to consumers.
Cloud Delivery
By using applications with popular device platforms, MVPDs can make VOD, live linear, recorded
content, and download-to-go content available to customer-owned devices on a cloud-delivered basis,
as permitted by content and distribution rights.
DSTAC WG4 Report
August 4, 2015
144
Section III: Implementation Analysis
Evaluation of “Competitive Navigation” System Proposal by Proponents of Application-
Based Service
The “CE Device “Competitive Navigation” System” proposal (“Device Proposal”) offers an approach
designed to permit device manufacturers to substitute their own user interface and guide for interacting
with MVPD services and to draw from the MVPD the program guide information from which they could
construct a different guide. The proposal is incomplete and omits many necessary elements necessary
to assure that consumers receive the services for which they have paid, that the contractual rights of
content owners are honored, and that MVPDs can continue to innovate and improve their services for
the benefit of all customers. On July 31, 2015, the proponents amended portions of their proposal. This
analysis has been updated to address those new portions.
How the Device Proposal Constrains the Tools of Innovation
The Device Proposal invokes some of the technologies that have been developed for innovative
platforms, but then removes the tools that make them platforms for innovation. For example, the
Device Proposal invokes Hypertext Transfer Protocol (HTTP), which serves as a content agnostic form of
transport for web content and video streams. But the Device Proposal restricts HTTP to the transport of
video and descriptive metadata, stripping the original and main purpose of HTTP - delivery of full web
pages and web applications.
48
The Device Proposal does not welcome the delivery of higher-level
protocols or applications. It wants only the video bits, and provides nothing at the application layer that
allows applications to operate in the manner that makes the Internet such a rich environment for
services.
The Device Proposal recognizes that the MVPD UI operates as integral part of service, but then calls for
the extraction of discrete elements of the UI, delivered via “HTML widgets” through an expanded
CableCARD MMI that is yet to be invented. The CableCARD MMI does not define how a hyperlink is
navigated and selected. Unlike the application environment we see today, the CableCARD has no
provision for JavaScript or other application execution environment in the Host device on the other side
of the CableCARD interface. The Device Proposal suggests the potential for interactivity in an expanded
MMI, but as the proposal stands today it does not offer any specifics; does not promise any capability
for maintaining state information in the retail device necessary for application data to persist across
widgets instances of the capabilities of this MMI; and provides no retail device query capabilities for
48
The amended proposal invokes misstated examples and misplaced analogies from the web. It claims justification
for using HTTP only for video transport by claiming that Netflix, YouTube and other online video providers limit
HTTP to such transport. In fact, Netflix, YouTube, Hulu and other online video providers use web pages to
distribute their content to PCs at a minimum. They may also provide native apps for platforms such as iOS and
Android that use HTTP for video and web services, relying on the native app platform for their UI. The proposal
also claims that hypertext and hyperlinks, the basis for modern web browsing, are intentionally defined separately
from the browser or other navigation technology to allow both sides of the interface to be flexible. But the
amended proposal is based on a set of yet to be defined network protocols and XML schemas designed to prevent
both sides of the interface from being flexible.
DSTAC WG4 Report
August 4, 2015
145
adapting to different retail devices to different MVPDs. An MMI has to have an execution environment
in the client to provide any form of interactivity, or it fails. But the Device Proposal provides for no
execution environment within which the widgets delivered through the MMI can operate. The
amended proposal states that the MMI offers a predictive execution environment; but the proposal
specifically states an intention not to offer a predictable execution environment on the device and
avoids specifying any standards for such an environment. All of these requirements have been
addressed in the MVPD app based proposal which proposes a full HTML5 web application environment
on the retail device.
The Device Proposal proposes “to determine the level of HTML that the MMI should support,” but offers
no reason why existing specifications like HTML5, EME, MSE and Web Crypto, all developed through the
W3C open standards processes, would not be a more appropriate solution, as proposed in the MVPD
WG3 and WG4 proposals. Instead, it would require essentially starting from scratch to determine the
requirements for the Device Proposal’s hypothetical MMI.
Moreover, the Device Proposal ignores the app-based model that has been widely deployed in the
marketplace. Consumers have eagerly and widely embraced apps as the dominant means of accessing
content and resources on their third-party consumer electronics devices. MVPDs have delivered on this
consumer demand, making available apps that enable their customers to access and view their services
on tens of millions of retail devices such as PCs, tablets and smartphones. MVPDs invest hundreds of
millions of dollars to deploy a network and CPE to provide service. These networks have constraints
based on the physical nature of the network medium (RF wirelessly or over coax, twisted pair copper,
light signals over fiber). The physical constraints drive network architectures and the capital investment
necessary to build and deploy the network and CPE devices. The app model helps preserve these
network optimizations by allowing the applications to be partitioned according to the network
architecture. Today’s most successful retail devices offer APIs that allow innovation on both sides of the
platform APIs (device side and application side)—but there are no APIs offered in the Device Proposal.
Instead, it removes any APIs and fails to provide an application execution environment, with the
expressed purpose of stripping out features of MVPD service.
The Device Proposal cites RFC 3439, but itself runs contrary to the End-to-End Argument and Simplicity
section in RFC 3439 (https://tools.ietf.org/html/rfc3439#section-2.1). It does this by establishing
network protocol interfaces to the proposed Virtual Headend at the application layer, thus requiring
coordination between all of the MVPDs and retail device manufacturers to affect any changes to these
interfaces. The End-to-end Argument recommends against these kinds of protocol definitions because
of the inherit inflexibility and burden it places on applications and the network. The MVPD Proposal in
contrast follows the OTT video distribution model by not introducing any new network protocols, thus
preserving the flexibility at the application layer that has resulted in the tremendous growth of the
Internet.
The Internet and Web protocol models are based on innovation at the edge of the network, e.g. at the
server and the client ends of the network and not with a dependency on some intermediary in the
DSTAC WG4 Report
August 4, 2015
146
middle of the network between these endpoints. These innovations on the server and the client app
happen together. Web applications have experienced explosive innovation because they have a
predictive execution and display environment on the client device (HTML) and a reliable communication
channel between the client and server (HTTP) free from intermediation or disaggregation by a third-
party in the middle.
49
Websites on the Internet are able to author web applications (through web
pages) that take advantage of the services provided by their web and back office servers and evolve
them together without the need to negotiate with a third-party when the client/server interfaces
evolve. The same is true of the mobile app ecosystems today. The mobile app platforms provide a
predictable execution environment on the client and the application developer can evolve their client
apps along with their server functionality without the need to negotiate with a third-party when the
client/server interfaces evolve. The retail proposal proposes to disintermediate or interfere with this
time proven model, by removing a predictive execution environment and freezing the client/server
protocols and interfaces.
How the Device Proposal Would Constrain Service
The approach of the Device Proposal would impose substantial losses in the multichannel services
ecosystem.
The Device Proposal strips out the very features with which MVPDs compete, improve service and
market to consumers, on every retail device envisioned by the proposal. Satellite customers would lose
sports scores and statistics for satellite. U-Verse customers would lose instant channel change. Cable
customers would lose StartOver and LookBack, telescoped and interactive advertising. Cable program
networks would lose the interactive enhancements they have built into their programming, such as shop
by remote and multiple camera angles. The amended proposal suggests that “some” interactive MVPD
features (such as Caller ID; sports statistics; News ticker) could be made available through an MMI
widget for optional incorporation by a third party UI. All MVPD features that Device Proponents do not
consider to be multichannel service would have to be entirely re-written and maintained in a new MVPD
“widget” format. Even then, the mechanism to make it available is not defined,
50
and the device
manufacturer is free to eliminate or block those features in its discretion, even if it is part of the MVPD’s
49
The Device Proposal flags a concern that current browsers support only one DRM each. While PC
browsers today only appear to support one DRM, CE devices, such as Samsung and LG TVs support
multiple DRMs. Mobile devices based on iOS and Android allow multiple third-party DRMs to be
implemented. Retail devices can clearly do the same, or can permit the download of different browsers
as desired or as they evolve. This is part of market evolution, and market forces will continue to apply.
50
Most UI is tightly coordinated with the video display, including overlays like caller ID and tickers. The Device
Proposal offers no mechanism for, say, the Caller ID to know where the top of the video is, for the ticker to know
where the bottom of the video is, when the video has been reduced from full screen, or how to coordinate with
captioning. All MVPD UI elements, including EAS and captioning are coordinated and tested together. A widget
running inside arbitrarily different device UIs offers no comparable reliability.
DSTAC WG4 Report
August 4, 2015
147
service as provided to subscribers. The Device Proposal does not offer a method for actually delivering
MVPD service as it has evolved or as it is offered, advertised, subscribed to and delivered. Nor does it
offer a means for accommodating the continued evolution of services, as applications do.
Because the Device Proposal does not deliver MVPD services as they are offered today, it calls for
MVPDs to invent a new and different service that includes far less. The Device Proposal defines three
interfaces through which service must pass: Service Discovery Interface, the Content Delivery Interface,
and the Entitlement Information Interface.
The Service Discovery Interface is limited to three elements: lists of available services; metadata about
those services; and messaging from the MVPD relating to these services. The metadata and messaging
related to these services significantly constrain innovation. The metadata in this interface is limited to
describing the service, but does not permit any method of enhancing the service itself (e.g. interactive
enhancements, multiple camera angles, request for information, telescoping ads, shop-by-remote etc.).
The messaging in the proposal is described as expanding the limited CableCARD MMI model that can
optionally displayed based on user input. While this appears to be describing a constrained HTML
“widget” model, the specific constraints are not explicitly identified. By contrast, the MVPD proposal
adopts the full W3C HTML5 model without constraints and thus includes much greater extensibility that
is achieved through the app model.
The Content Delivery Interface constrains the types of content and the method of protecting those types
of content to a limited set. Interactive enhancements to the content are not addressed or envisioned in
this proposal. Nor is there a process identified for how any of these interfaces would evolve over time,
in order to phase out obsolete technologies/features and introduce new technologies/features. DLNA
and other multi-stakeholder organizations facilitate the evolution of their specifications and standards
to keep up with technology evolution. The application model allows for rapid innovation and change.
The Content Delivery Interface and regulatory mandates have none of these mechanisms.
The Entitlement Information Interface is described as “defin[ing] a common platform for publishing,
communicating, sharing and transferring rights information.” The proposal does not provide any details
for how these rights are expressed or transferred. The expression of rights through a limited set of Copy
Control Information (CCI) bits has proven to be one of the most limiting factors in the CableCARD
model.
51
There is no indication of how modern business models could be expressed if the only interface
from an in-home device is DTCP. After this was pointed out, the Device Proponents shifted their content
protection analysis to invoke DTCP-2, which is in development. But they have not addressed what DTCP-
2 entails or how it will support the extensive and dynamic business models that are today handled by
multiple competing DRMs as in the apps model. The proposal provides much more detail about device
authentication through the use of X.509 certificates, yet fails to provide the critical and necessary details
51
For example, CCI bits do not cover EST, expiration date, or communicate license restrictions on in-
home or out-of-home distribution.
DSTAC WG4 Report
August 4, 2015
148
about how these certificates are managed, the required trust infrastructure, certification, and any
policies necessary to make the certificates useful.
The amended proposal acknowledges that standards do not exist for the interfaces it envisions, which it
tries to characterize as a forward-looking virtue. In fact, assuming an un-invented standard ignores the
technological variation in systems. MVPDs use apps to deliver services because apps can be tailored to
the very different technologies and resources used in widely varying MVPD networks. The many
different VOD systems, for example, can operate on mobile devices because specific MVPD code can be
downloaded to apps platforms. The “virtual headends” and standardized protocols envisioned by the
Device Proposal would require MVPDs to rearchitect and duplicate their networks to serve such devices.
These interfaces are all uni-cast and preclude any multicast efficiencies that could offered in a cloud
based virtual headend. The Device Proposal claims to permit an MVPD to operate a Virtual Headend in
the cloud, and use multicast for bandwidth efficiency. But the proposed interfaces are unicast, and offer
no method by which multicast gets carried on the home network. This forces the MVPD to put a
gateway (virtual headend) in the home even if it would be more efficient to use multicast over the
access network.
The Device Proposal would impose burdens, costs, and losses onto service providers, consumers, and
content owners, just to convert MVPDs from service providers into delivery vehicles for raw video
programming (and program guide metadata) feeds from which Device Proponents may build their own
services with no license from or responsibilities to the content providers who own and license that
copyrighted content.
All of this is offered in supposed service of facilitating a third party program guide (and a third party
service), but no evidence whatsoever has been presented to the DSTAC to indicate that such a guide is
the recipe for success of competitive navigation devices, or that customers want the device maker to
block available MVPD services. CableCARD devices have enjoyed very limited commercial success. TV
manufacturers stopped supporting CableCARD interfaces early on,, and Microsoft is terminating support
for the Media Center PC,
52
for which the CableCARD OCUR was designed. In contrast, the apps approach
has radically expanded the number of video devices on which consumers can enjoy their MVPD and OTT
services. With an applications approach, the retail device can have its own distinctive top-level interface,
app store, and menu structure, and can also differentiate itself with features, functions, look and feel,
network interfaces, drives, speed and price. Further, the retail device manufacturer is free to choose all
of the specifics regarding the app platform, the DRMs supported, the app store, and the app approval
process for their retail devices. Roku has sold over 5 million of its retail set-top boxes that rely entirely
on apps (including a cable operator app with a cable-operator supplied guide), outselling TiVo (with its
“third party” TiVo guide) five-to-one. The Apple iOS platform, cited by Device Proponents as the most
successful, follows the same app-based approach. And VidiPath and RVU were developed in open multi-
52
“Confirmed: Media Center is Dead,” https://www.thurrott.com/windows/3319/confirmed-media-
center-is-dead (May 5, 2015)
DSTAC WG4 Report
August 4, 2015
149
stakeholder consortia that included CE and MVPD participants. Rather than being “deliberately
designed” to preclude a third-party user experience, these apps-based solutions represent what the
open and competitive marketplace determined were the appropriate standards for extending MVPD
services to retail devices.
53
Nor is the Device Proposal consistent with Section 629. While Congress authorized the FCC to require
unbundling of incumbent Title II local exchange carrier network elements, it did so only with carefully
crafted limitations to which the FCC has been strictly held to by the courts. The FCC has no such
unbundling authority under Title VI. Section 629 addresses the availability of retail devices that can
receive multichannel services and other services “offered” and “provided” by MVPDs, not to
disassemble those services for third parties to create new services. Title VI bars the FCC from
“impos[ing] requirements regarding the provision or content of cable services, except as expressly
provided in [Title VI].”
54
CableCARD is Not the Starting Point for DSTAC
The Device Proposal frequently invokes CableCARD and CableCARD technology as a benchmark for
future retail navigation devices.
The CableCARD/UDCP model adopted more than a decade ago was designed only for reception of one-
way linear cable channels from digital cable systems,
55
and required retail CableCARD devices to use
their own guides. This approach reflected basic technical limitations at the time – a one-way device
could not support interactive services or the cable program guide, and suitable remote user interface
technology did not exist. The resulting devices met with very little consumer acceptance.
56
Compared
53
VidiPath was developed in DLNA by major retail device manufacturers (including Samsung, Panasonic
and Sony); major chip manufacturers (Intel and Broadcom) and major MVPDs (including Comcast, TWC,
and AT&T). Although the Device Proposal calls VidiPath “interim,” there is nothing “interim” about
VidiPath or other gateway solutions. For example, ABI is projecting that VidiPath Certified devices will be
available in approximately 40 percent of all U.S. cable households that subscribe to advanced services by
2016, and 70 percent by 2020. The Device Proposal also mischaracterizes VidiPath as some sort of
transitional black box that “converts” video services to unbundled IP streams. As detailed in the Report,
VidiPath is app delivery vehicle. Nor does cloud to ground delivery “terminate” an MVPD’s proprietary
network. It delivers an app that interacts with the server(s). The RVU Alliance standards organization
reported to the FCC that successful market-driven technology like RVU is less likely to be able to bring
the advantages of the RVU RUI technology to consumers if that technology becomes a target of
regulation. http://apps.fcc.gov/ecfs/comment/view?id=60001059431
54
The amended proposal claims that STELAR is a Congressional directive for the FCC to replace apps-based delivery
of MVPD service. When STELAR was being negotiated in Congress, a proposed amendment would have assigned
DSTAC an expansive mission to develop a new technology mandate for the FCC to adopt by rule. The sponsor
lacked support for that proposal, withdrew the amendment, and that provision is not part of the law.
55
CableCARD was designed for cable architectures, business practices and infrastructure, not for satellite and IPTV
distributors. It was only implemented by cable systems.
56
The amended proposal takes issue with the support provided for CableCARDs. The extensive support is
catalogued at Comments of NCTA, CS Docket No. 97-80, http://apps.fcc.gov/ecfs/document/view?id=7020514104
(Timeline of Cable Industry Support for CableCARDs)
DSTAC WG4 Report
August 4, 2015
150
with the fewer than one million retail CableCARD devices today, there have been over 56 million
downloads of MVPD apps (as of July 23, 2015), with millions more occurring every month.
Notwithstanding the limited successes of TiVo Series 3+, SiliconDust and Hauppauge devices,
CableCARDs have been neither “upgradeable” nor conducive to innovation. As reported by WG2, the
requirement to use CableCARDs in leased devices delayed cable operators’ transition to all-digital and
use of switched digital video. Verizon had to bolt on a redundant method for delivering entitlements to
UDCPs using CableCARDs – using a slower carousel approach for which CableCARDs were designed
rather than the instant entitlement designed for FiOS. Verizon also had to add additional EAS and OOB
signaling just to address UDCPs using CableCARDs. FiOS IP services do not pass through the CableCARD.
The CableCARD’s limitation to 1995’s MPEG-2 Transport Streams is incompatible with modern video
delivery formats (e.g. ISO Base Media File Format) used by competing video providers. Very limited
innovation has occurred in CableCARD devices. For example, the CableCARD was changed to support
multi-stream and SDV tuning adapters, but only with time consuming re-engineering and high cost. CE
device manufacturers and MVPDs have innovated around the CableCARD to reach a wide variety of
retail devices, with hundreds of new MVPD services, using the more widely adopted web- and app-
based approach.
From the outset, the presence of a third-party program guide on UDCPs was designed to be transitional.
By the terms of the MOU and the FCC’s implementing rules, UDCPs were designed as one-way devices.
As they transitioned to interactive devices, they were to present the full cable service using an apps-like
approach running on common middleware, not on protocols.
57
By rooting itself in technology that is
more than a decade old rather than in modern applications, the Device Proposal would impose even
more constraints on innovation.
Use Cases Supported
Tuning and Viewing a Linear Channel
Although the Device Proposal claims to support the delivery of linear services, it is impossible to
determine that it would. It identifies a number of protocols, but does not specify which would be the
preferred embodiment. It invokes standards that are not implemented (e.g. SCTE 65 Profiles 4-6 and
CEA 2033) or standards that are implemented only by some MVPDs (e.g, Zeroconf which implies a
57
2002 Memorandum of Understanding, FCC 03-3, 18 FCC Rcd 518, 548,
http://telecomlaw.bna.com/terc/core_adp/get_object/FCCRCD18-518.pdf (“for Advanced Interactive
(two-way) Digital Cable Products … Cable operators’ EPG will be provided for advanced interactive
digital cable products via OCAP or its successor technology.” ) For some reason, the Device Proposal
detours to call OCAP ‘antithetical to a competitive experience.” Panasonic built a two-way OCAP TV, but
CableCARD-enabled TVs disappeared because consumers rejected the $300 or larger markup that
retailers attached to them. See First Panasonic Tru2way TVs hit stores in Chicago, Denver, CNET
(October 16, 2008), available at http://www.cnet.com/news/first-panasonic-tru2way-tvs-hit-stores-in-
chicago-denver/ . (“The Panasonic Tru2way models will be priced at $1,600 and $2,300 for the 42-inch
and 50-inch model, respectively … a premium of $500 to $670.” The editor added his prediction: “Few
people are going to accept a 45 percent surcharge for the privilege of losing their cable box. The
premium for Tru2way compatibility needs to get closer to the $100 range--at maximum.”) The market
has since moved on to apps on Smart TVs, which operate as in the MVPD proposal.
DSTAC WG4 Report
August 4, 2015
151
particular provision, management, and fault detection system in the MVPD’s network.) It is not
sufficient to simply name a standard without a more detailed description of what parts of the standard
are implemented, and how, preferably with a certification program and reference implementation as is
done with VidiPath and RVU. The Virtual Headend System proposal – which is not even reflected in its
supposed schematic -- will in fact require that all operators radically re-architect their networks. Among
the service features that would need to be re-architected are: Instant Channel Change (ICC),
58
Switched
Digital Video (SDV), Video-on-Demand (VoD) in all forms (transactional, subscription, free, etc.),
Electronic Sell Through (EST), Pay-Per-View, blackouts, zone based ad insertion, promotions (e.g. buy-
one, get-one-free or try-and-buy or upgrade service, etc.), and any interactive service features (e.g.
interactive shopping, interactive advertising, request for information, telescoping ads, etc.). It would
represent a significant, burdensome, and time-consuming development effort to standardize these
protocols. It also represents an entirely redundant architecture to the solution MVPDs are actually using
today to delivery such features.
The Device Proposal does not even support linear channels within its own terms. It explicitly
acknowledges reliance on “prosthetic” auxiliary devices for satellite and IPTV, at the very least –
meaning more boxes (and more energy consumption). It also assumes a separable tuning adapter box
to support cable SDV, rather than considering an application based approach that has already solved this
problem.
59
These additional MVPD-provided devices would be required for any consumer who sought
to use a retail device in their home. By comparison, the apps model today delivers a full user interface
for an MVPD service to a smart TV with no set-tops or gateway devices required at all beyond the basic
network modem.
The Device Proposal acknowledges that it is unacceptably burdensome to rebuild all MVPD systems.
60
But the Device Proposal does not take account of the technological differences among them, and thus
58
The amended proposal claims that U-Verse could implement fast channel change under in its implementation of
the Content Delivery Interface in the Device Proposal. This is incorrect. In order to implement instant channel
change, the retail device must implement the proprietary Media Room protocols, otherwise, ICC cannot be
implemented, nor can it be implemented in a U-Verse gateway. The amended proposal also states that ADSL
modems serve as Provider Interfaces in AT&T U-Verse. U-Verse is actually provided through VDSL gateways, which
are not strictly a bridging modem, and implement the proprietary Media Room protocols that facilitate multicast
and ICC.
59
As an alternative, the Device proposal seeks to reduce the various competing SDV systems to one
universal web based approach, with no assured mechanism for the retail device to release the
channel—which is essential to recovering bandwidth for reuse. We are benefiting from a competitive
and evolving market in SDV technology, already evolving beyond QAM delivery. AT&T’s Media Room
implementation uses a proprietary version of multi-cast IP and ICC. CableLabs recently published
multicast IP specifications for video distribution based on NORM (available at:
http://www.cablelabs.com/specs/specification-search/), which is currently under consideration within
DVB. Imposing a single uniform approach will arrest this innovation in dramatically improving
bandwidth utilization.
60
The Device Proposal notes that in general, only such devices as are designed for the various proprietary systems
and authorized by the specific MVPD can connect directly to the MVPD network to achieve full access. In some
cases, this can be part of security. Pirate devices are best dealt with if they can’t “connect” to DBS broadcast
service.
DSTAC WG4 Report
August 4, 2015
152
would require exactly that kind of rebuild to engineer a Virtual Headend, widgets apps, and other
unspecified technologies..
The Device Proposal asserts that because one MVPD is using a particular protocol or architecture, all
MVPDs can use the same protocol or architecture. As one example, its premise is that all of these
technologies are transitioning to IP and may readily converge on one solution in IP. This view ignores
the diversity of MVPD network technologies and architectures. Because of that diversity, while MVPDs
are adding IP delivery to their service, they are not all doing so at the same pace or through the same
architectural approach. DBS systems will never evolve to IP carriage or encapsulation of their broadcast.
As another example, the Device Proposal calls for unicast delivery to a retail device. The AT&T service
architecture is based on a proprietary Media Room implementation that uses a multicast IP distribution
to the end client that makes use of a proprietary Instant Channel Change protocol as well. The entire
system is built around a distributed model that shares stream coordination to manage the U-Verse
service within the limited bandwidth available on VDSL. For AT&T to build a Virtual Headend as called
for in the Device Proposal it would need to re-architect its multicast end-to-end model to one that
breaks the multicast at a new gateway device and translates it into multiple uni-cast streams.
As a third example, the Device Proposal calls for MMI to deliver a widget to the device side of its
interface, but DirecTV’s RVU does not message its MMI—it is presented to the screen. The Device
Proposal would add substantially to the complexity of in home DBS equipment in order to convert it to a
“Virtual Headend”—something such equipment was never designed to be.
As a last example, the Device Proposal states that because many MVPDs already have deployed
equipment in the home, they “may be convertible to an interim gateway by enabling the Ethernet
interface already on the device.” This optimistic theory is unsupported by any analysis, even a cursory
one, and runs counter to the decades of experience of MVPDs who continually deploy new generations
of in-home hardware after previous generations are found to lack the ability to accept new, more
complex and larger software downloads that expand capabilities and provide new features. This is one
of many ways in which the Device Proposal minimizes the effort required to separate out the various
components that make up linear programming and make those components compatible with its
proposed static architecture. The Proposal does not consider the burden imposed on the MVPD’s
system to deliver features, ad insertion and other components of the MVPD service over the proposed
interfaces. Different networks use different approaches to optimize their technology for delivering
competitive service. MVPD service is not a collection of “content items” and “micro-services.” Most
MVPD apps will or have the capability to hit multiple servers for data necessary to provide the service as
an integrated whole. Different networks use different approaches for sound technical reasons. It is no
trivial task to create and utilize an interface different than the one that has been optimized for the
MVPD’s specific network. For example, the Device Proposal does not even attempt to replicate rights
protection like geo-fencing that occur in the device for networks that are optimized to broadcast all
services to the device. That is why applications have developed as the bridge. Application code this
diversity and complexity inside the app, delivering to an ever-increasing number of retail devices,
without ever having to build a parallel network or slow network innovation.
The Device Proposal supports advertising inserted at the network source into the linear channel, but not
interactive requests for information, telescoping ads, or promotions. It provides no local support for ad
lifecycle management, audience measurement, or ad measurement and reporting, all of which is
DSTAC WG4 Report
August 4, 2015
153
measured in the home and requires an app or return path. The Device Proposal does not provide the
tools to support the advertising that funds the dual-revenue MVPD business, or to provide an interactive
and accountable ad platform that can continue to compete for those ad revenues. By contrast, Roku’s
app-based approach supports audience measurement, interactive advertising, its own ad business and
the MVPD’s app-based business.
61
Advertising is a $25 billion annual business for multichannel services;
without support designed into a system proposal, ad dollars and financial support will flow to other
platforms, to the detriment of MVPDs and their subscribers.
Cable operators are required to restrict the display of commercial web links in association with
programming directed to children. The Device Proposal offers no restriction against prohibited ad
overlays, whether agreed upon with content providers or required when airing children’s programming.
The Device Proposal offers no support for EAS. EAS is delivered through a variety of means across
MVPDs (e.g. in-band vs. out-of-band signaling, presentation differences, text crawl with audio override,
forced tune, barker channel, etc.). Those differences can be abstracted through an application-based
approach, but there is no indication that the EAS via MMI can be implemented across all MVPDs. In fact,
if MMI display is only allowed as an option, EAS could not operate as intended. After this was pointed
out, the Device Proponents proposed that consumers could not opt out of EAS—but that device
manufacturers could still opt consumers out of virtually every other feature of service.
62
Cable operators provide parents the ability to block channels they consider offensive regardless of
rating. The Device Proposal offers no support for parental controls, including device restrictions (e.g., by
channel, rating, time-of-day, etc.). Parental control entered through the MVPD’s user cable box or MVPD
website would not prevent delivery of restricted service to the retail device. Each retail box would need
to be independently programmed for a consumer to be assured of receiving the protections they
sought.
Cable and satellite operators are required to protect the privacy of the video records and other
personally identifiable information of their video subscribers, particularly against government intrusion.
The Device Proposal offers no support for statutory privacy.
Analysis of use of Sat-IP
Sat>IP was developed for a European DTH model which features satellite operators, device
manufacturers and service providers acting independently to serve a variety of consumer television
regional markets and business models (e.g. free to air). The US DBS model, on the other hand, consists
of two vertically integrated (i.e. each acting as a service provider, a satellite operator and a device
61
“Roku Unveils Advanced Video Advertising and Measurement Solutions,”
https://image.roku.com/ww/press/2015/Roku_Unveils_Advanced_Video_Advertising_and_Measureme
nt_Solutions.pdf
62
The amended proposal erroneously states: “The VidiPath and RVU section of this document states that despite
the ‘variety of means’ for delivery of EAS, they abstract them to a common protocol (W3C’s Server Sent Events
(SSE)) such that the VidiPath and RVU clients do not have to implement all of the different methods.” This is
incorrect. SSE are included in VidiPath and are one option that an operator can be used for EAS, but there is no
standardization of EAS protocols in VidiPath. The VidiPath app code allows each operator to connect to their
different EAS protocols and present in their different user interfaces.
DSTAC WG4 Report
August 4, 2015
154
manufacturer) companies competing in a single consumer market. As a result, the benefits that the
Sat>IP standard might allow in the European DTH model do not necessarily accrue to the US model. In
fact, when applied to the US model the Sat>IP standard introduces new problems that would have to be
addressed.
For example, the key benefit of the Sat>IP standard for the European DTH model is how it allows the
satellite RF tuner and demodulator functions to be separated from the in home receiver, making these
functions available as a single resource to other devices on the home IP network. As both US DBS
operators have embraced whole-home architectures (in which a single STB performs all satellite RF
tuner and demodulator functions, and then performs IP streaming to simple IP devices in other locations
in the home), this primary benefit of Sat>IP has already been addressed.
At the same time, this separation of the satellite RF tuner and demodulator functions from the
decrypting/decoding functions of in home receivers introduces many new issues, including:
- Tuner resource allocation: In a system having only two tuner resources, for example, if one
device will be needing two tuner resources and another device will be needing a tuner resource
later in the day, there isn't a mechanism via Sat>IP for the conflicting uses to be prioritized and
resolved. In comparison, resource management is handled very simply and effectively in a
whole-home Genie or Hopper architecture. In fact, Sat>IP would not have necessarily allowed
Dish's innovative "Primetime Anytime" feature, in which a single tuner resource enables
simultaneous recording and/or viewing of four different TV channels, to have been launched.
- Signal security: Either the Sat>IP tuner resource must perform CA/DRM descrambling, or each of
the devices on the home IP network must do it: in either case security risks are increased when
compared to the whole-home model that's already proven cost effective and secure.
- Rapid technology changes: The vertical integration of each US DBS service has allowed each to
continually optimize signal capacity and installation efficiencies through rapid introduction of
new and typically non-standard technologies. Historical examples include new modulations (e.g.
Dish's proprietary 8PSK/Turbo) and frequency plans (e.g. DIRECTV's transponder bonding and
"reverse band" operations). Each of these would have required changes to Sat>IP, changes
which wouldn't necessarily have been possible in the time frames required by either US DBS
operator.
On-Demand Content
Even assuming many required inventions that are undescribed, the Device Proposal would support
delivery of VOD, but not a robust verification and audit platform required for the delivery of VOD assets.
It would not support EST, Start Over or Look Back. EST grew 30% in 2014 alone, but the Device Proposal
would not permit the MVPD to continue growing these purchasing options for consumers.
The Device Proposal does not support dynamically locally-inserted pre-roll advertising or disabling fast
forward during advertisements included with VOD content as is often required as a condition to offering
certain content on an on-demand basis.
The Device Proposal does not support user authentication (e.g. PIN and/or password entry).
Pay Per View (PPV) events
The Device Proposal includes no local support required for purchase and cancellation windows, secure
purchase credits and purchase limits.
The Device Proposal does not support user authentication (e.g. PIN and/or password entry).
DSTAC WG4 Report
August 4, 2015
155
Navigation
Since the Device Proposal intentionally prohibits the MVPD’s user interface, there is no MVPD UI for
interacting with the MVPD’s experience.
The Device Proposal proposes to reduce the MVPD UI to a small set of widgets. But the MMI or widget
model envisioned is event driven from the MVPD side only. There is nothing that envisions a subscriber-
initiated communication to the MVPD, such as upgrading or downgrading service, ordering technical
assistance, subscriber profile changes, parental controls, or a subscriber paying a bill. The Device
Proposal claims that HTML widgets are suitable for communicating with all backend systems, but
nothing has been described that would assure that functionality across all systems. The proposal states
that “display of widgets must be optional” so there is no guarantee that any MVPD or consumer
interaction will occur. The UI is not some “monolith” overlaid as a “micro-service” on top of “content.”
It is integral to service. Most of the modern MVPD UI exists in a context that extends within and across
video channels—such as saving a subscriber’s viewing history for purposes of navigating back through
his viewing history or making recommendations across devices. Even if an adequate number of widgets
could be identified, such functions need to operate in context—which is why their functionality is
integrated into full UIs.
With the loss of the MVPD’s user interface, consumers do not receive a common familiar experience
across devices—TVs, tablets, smartphones, and set-top boxes. Thus, the consumer must learn anew the
navigation of an MVPD services for each different retail device they have purchased.
After this was pointed out, the Device Proponents added a vague suggestion that the MVPD’s full UI
could be presented to run on the device. But the proposal continues to eliminate the APIs and
application platform to make that work; would require most elements of the UI to be rewritten into
widgets, and the others to be exported to the web; and even then, the device manufacturer could block
it.
63
The Device Proposal fails to enforce requirements from content providers, including channel
presentation in required neighborhoods (e.g., news channels) and channel assignments (e.g.,
broadcaster carriage on channel); channel logos; and search requirements (i.e., all shows accessed from
a program network-branded folder).
Under the Device Proposal, third party devices could rearrange channel or program placement, insert
different advertising into or on top of programs or use search functionalities to promote illegitimate
content sources over legitimate ones. A user about to purchase an on-demand movie might be directed
to a lower-cost pirate option. A programmer’s title might be placed next to an X-rated offering, in
violation of the programmer’s carriage agreement. The retail device might also use search
63
The amended proposal elaborates on a to-be-invented MMI (a subset of HTML5) as sufficient for all MVPD user
interface purposes. The W3C has worked since 1994 to create a platform neutral Man Machine Interface, and
HTML5 with the EME, MSE, and Web Crypto extensions is the only MMI that works across virtually all devices.
Other efforts to create MMI systems are largely device specific. Android, iOS, and Tizen are among the few
platforms that support a range of devices (TVs, tablets, smart phones, and smart watches), but they represent
apps platforms in and of themselves. To assume the ready creation and sufficiency of a new widget-based MMI is
wishful thinking.
DSTAC WG4 Report
August 4, 2015
156
functionalities to promote, or otherwise skew how consumers identify and choose which content to
watch (such as manufacturers charging content sources to improve their search rankings).
Recording Linear Content
The Device Proposal asserts that it supports local recording while VidiPath and RVU do not. That is
mistaken. Both VidiPath and RVU present recordable outputs that are accessible by a third-party UI.
The ability to record the video output from either a VidiPath or RVU server is controlled exclusively by
the rights conveyed by the content protection system in use, either DTCP-IP or DRM. Nothing in
VidiPath or RVU prohibits this recording. Output is in standard audio-video formats defined by DLNA. If
the rights allow for recording the content, the device can record the content (provided they support the
content protection system in use). Once the user has navigated to the content of interest on the client
device, there is nothing that prevents the client device from recording the content provided the content
rights allow it. Neither VidiPath nor RVU specify how this recording is to be performed or played back.
The client device choses its method for implementing this functionality using its own UI outside of the
RUI provided by either VidiPath or RVU.
The Device Proposal suggests unrestricted transfers of recorded content to mobile devices. There is no
indication of an intention to respect restrictions by content providers on distribution generally or
distribution to mobile devices.
The Device Proposal seeks access to an MVPD’s network DVR. Network DVRs are implemented
differently, according to rights and technology. MVPD’s network DVR utilization is inextricably linked to
the MVPD UI and to applications that encapsulate these differences. The Device Proposal has rejected
both the UI and apps.
Remote Management by Consumer
The Device Proposal does not support remote management of tuning or of the account by a network-
connected mobile device.
As detailed above, the Device Proposal does not support user-initiated management functions such as
billing systems or a subscriber’s ability to upgrade service from the screen.
Customer Support and Remote Management by Service Provider
The Device Proposal would leave MVPDs without important customer service tools. The proposal claims
to offer an MMI channel for communications, but there is no continued presence on the device to
support customer inquiry, no tools to know how service is being rendered on the device or to diagnose
problems, and no tools for solving the customer’s problem. After this was pointed out, the Device
Proponents proposed that any service support be exported to an MVPD web service on the general
Internet. This would require a redesign of service support and remove key elements of the UI and
service support from the screen where it is most useful to consumers. Every major MVPD offers FAQs
and online support for the delivery of their service (in its entirety) and as presented via their UI. Some
even offer mechanisms to take control of CPE to obtain more technical detail and diagnostics.
Increasing efforts to promote customer service and customer satisfaction is an imperative for MVPDs,
but because there is no support for remote diagnostic service there is no assurance that the CE device
will be a reliable platform for customer service. Customer support for an ongoing service differs from
customer support for a device. For example, Google abandoned its first mobile phone because it was
DSTAC WG4 Report
August 4, 2015
157
unaccustomed to the retail service space. The Device Proposal fails to support MVPDs’ efforts to assure
quality of service in delivering video and to diagnose problems remotely.
Installation and Provisioning
Device Operation Requirements
User Authentication
The Device Proposal does not support these use cases.
Evaluation of Burden
Consumer Experience
The Device Proposal rejects the successful apps model developed in the market and widely adopted by
consumers. As noted, the Device Proposal does not offer a method for delivering modern MVPD service
as it is purchased by consumers.
The proponents of the Device Proposal have tried to characterize these features as optional or
extraneous to the MVPDs’ services, that the consumers who would use their retail devices would be
happy to forgo. The MVPDs disagree, but however an individual customer values a particular feature,
the MVPD business depends on its ongoing ability to rapidly make new features available to existing
customers so that it can continuously strive to improve its service in a fast-evolving, competitive market.
A customer that accesses only disaggregated portions of the MVPD’s service under the Device Proposal
would thus remain stuck in the past, potentially unaware of new distinctive differences in features,
offerings, and look and feel of their MVPD’s service. Application and feature updates are occurring
multiple times a month, effected with an application update, as consumers have grown accustomed to
on tablets and smartphones. The Device Proposal accepts only the raw linear and VOD that passes
through its limited interface with no mechanism for updates or improvements.
Ordinary expectations—such as that parental controls entered into the MVPD UI will block programming
on other connections in the home—will not be fulfilled. Each retail box needs to be independently
programmed.
Cable operators are required to put their service phone numbers on every bill. But the Device Proposal
will not enable customers to receive adequate troubleshooting, remote management, or technical
support from their MVPD to fix service problems on their retail devices.
Development and Testing
The Device Proposal hypothesizes a Virtual Headend System that does not exist; invokes standards that
are not implemented at all or and standards that are implemented only by some MVPDs; and calls for
the rebuild of existing architectures. It negates the successful app development work that every one of
the top 10 MVPDs undertook in response to demonstrable consumer demand. It removes APIs from
devices and strips out applications that make service work. It instead calls for multiple new inventions,
and the development of protocols, prosthetics, auxiliary devices, transcription and virtual headends in
order to cover all architectures. Then comes the cost of implementing them, mapping them to existing
systems, and transitioning to them over time.
DSTAC WG4 Report
August 4, 2015
158
The Device Proposal fails to offer essential procedures for testing and certification. Even after this was
pointed out, the Device Proponents leave the matter “to be determined.” Based on past experience,
the effort necessary to create a functional and operating testing regime is a multi-year process. In the
apps-based approach, extensive testing is performed on proprietary devices (e.g., iOS and Android),
while DLNA has stood up multiple commercial test houses around the world to test VidiPath and RVU
products to ensure conformance and interoperability for CE device consumers.
The Device Proponents have shifted massive burdens, costs, and losses onto service providers (and their
customers). It would take years to develop the hundreds of protocols for use across all MVPDs,
64
and
even then the protocols may not anticipate new services, features, or technologies for MVPD
distribution. The claim is that this is needed to “keep the burden of implementation and licensing
concerns minimal to a third party.” But in fact, none of this is needed: an application-based system also
keeps the burden of implementation and licensing concerns minimal to a third party, and does so while
preserving innovation and competition.
Service Provider
The Device Proposal proposes limited interfaces that strip out key features of the MVPD service.
Current or future features that are not carried across these interfaces cannot appear on the device.
Service providers cannot present the service, and consumers cannot receive it, as they could with an
updated app. The User Interface – which makes everything from promotional messages to StartOver to
parental controls work – has been reduced to discrete optional popup widgets lacking any application
support. Messaging and functions that cannot pass over a non-existent MMI must be abandoned. For
example, under the Device Proposal, an MVPD could no longer offer a consumer the ability to instantly
upgrade to add a channel through the guide, one of the most convenient and effective means for
managing subscriptions.
The Device Proposal provides for no presentation of the brand identity of the MVPD’s service.
Nor can MVPDs invent around the interfaces. The protocols are fixed, but business models and
entitlements change rapidly. The proposal makes vague references to later “extensions of the interface
protocols.” Protocols freeze business models until you agree on exactly what rights are allowed and
how to express them.
The Device Proposal also stymies innovation in content protection. It appears to require one single DRM
(recommending PlayReady) for cloud to ground, rather than allowing competition and resulting
improvement.
65
It also appears to require one link protection for the home (DTCP-IP), but DTCP-IP lacks
the rich rights expression language expression featured in (ever evolving) DRMs. The Device Proposal
offers no ability to support those models other than the ill-defined MMI, which does not enforce rights
like expiration. Fixed protocols require long timeframes for standardization of each new feature, which
64
Estimates from among the top 10 MVPDs indicate that the number of protocols or APIs in each of their systems
to deliver the MVPD service range from hundreds to as many as ten thousand.
65
Major device makers, like Apple, do not support PlayReady.
DSTAC WG4 Report
August 4, 2015
159
is difficult given the variety and pace of change among video providers, technologies, platforms, services
and features.
The Device Proposal also threatens to undermine the very security that is central to MVPD distribution
systems by creating a single national point of attack at the interface.
66
There would be no choice in
DRMs from the cloud, and no choice beyond a single link protection in the home. The proponents claim
that an in-home gateway advertises services only on the managed IP network. But they refute that claim
by calling for an SDV client that operates only over the open Internet.
The Device Proposal also proposes to define an entirely new Public Key Infrastructure (PKI) from scratch.
This is a non-trivial exercise. The proposal mentions X.509 certificates, yet stops short of providing the
critical and necessary details about how these certificates are managed, the required trust infrastructure
(issuance, injection, protection, propagating revocation lists and requirements to query CRLs), and any
policies necessary to make the certificates useful (profile, fields and information).
67
The amended
proposal gives only a gesture to these many deficiencies, noting that revocation will need to be
developed. Certificate revocation is one of the most challenging aspects of any public key
infrastructure. It took DTLA, DOCSIS, and even CableCARD years to establish an appropriate PKI.
Further, these PKIs are not static; it is necessary to continue to enhance these PKIs over time to address
new and growing threat models.
68
All significant burdens are asymmetrically imposed on service providers. The consumer devices do not
need to implement any network-specific technology such as physical tuners, however non-IP MVPD
operators must provide gateway devices that encapsulate their content into IP for transport within the
home.
The Virtual Headend proposal also does not propose any method by which copy control information
(CCI) or any other content usage rights are transmitted or implemented by or carried through to the
downstream outputs of the retail device. And, as noted above, when using the CCI method, MVPDs
would be frozen to very limited business models; EST, expiration date, or license restrictions on in-home
or out-of-home distribution are not communicated with CCI.
66
The section “Practical System Design Concerns” starting on page 193 of the amended proposal presents a new
theoretical system proposal, not previously presented or discussed, rather than an analysis of the Device Proposal.
The casual invocation of textbooks and a NIST reference is a far cry from designing and implementing a content
protection system that protects content providers or their distributors.
67
Nor has the Device Proposal included a functional approach to device authentication. It assumes the availability
of an HTML-page for authentication in unidirectional systems, and a monthly renewal of temporary device
certificates that would entail nontrivial engineering, operations, and bandwidth resources on DBS. Even after this
was pointed out, the Device Proponents leave unidirectional systems to develop an undefined “offline” method to
provide certificates by sideloading. It agrees that each MVPD will have unique operational requirements and
needs, but offers no practical provision for how those needs would be met.
68
The amended proposal compares its suggested PKI system as superior to “proprietary ones like in the MVPD UI
proposal.” The apps-based proposal does not specify a PKI.
DSTAC WG4 Report
August 4, 2015
160
The Device Proposal does not permit MVPDs to fulfill the many consumer protections (like statutory
privacy requirements), “must carry” rules (like channel position and channel neighborhood), and other
requirements built into regulated MVPD service.
The Device Proposal does not permit MVPDs to offer their services consistent with the content licenses
and retransmission consent requirements under which they acquire distribution rights. For example,
using native architectures or apps, MVPDs may assure that programming is kept in the right
neighborhood, such as a news channel placed in a news “neighborhood” or a premium service kept
adjacent to its multiplex channels. They may assure that search returns do not place a programmer next
to an X-rated offering. Under the Device Proposal, the MVPD cannot fulfill these requirements. The
Device Proposal now acknowledges this lack of protection, but declines to advance a proposal that
respects these licensing conditions. Instead, the proposal now suggests that all aspects of the
numbering, grouping and presentation of channels be defined by FCC regulation rather than
marketplace arrangements that reflect copyright license conditions, retransmission agreements, local
laws and expectations, and an MVPD’s own decisions about how to present services—decisions that are
protected by the First Amendment.
Customer support is a necessary and large expense borne by an MVPD and passed along in its
subscription costs to its customers. Consistency is a massively useful tool to control these costs and keep
subscription fees low. The Device Proposal does not permit MVPDs to operate with such consistency.
The Device Proposal calls upon MVPDs to serve as delivery vehicles for raw video programming (and
program guide metadata) from which Device Proponents may build their own services. MVPDs are not
licensed by the content providers who own and license that copyrighted content to serve that role.
The same problem arises with the Device Proposal’s requirement that program guide data be
disassembled and delivered. MVPDs do not own guide data—they license it for limited uses from third
parties. The Device Proponents agree that CableCARD only supplied minimal data and left it to the
device manufacturers to license metadata from third party sources (e.g., Rovi and Tribune Media
Service) and build their own guides. Under the applicable MOU, license and FCC rules, UDCPs only
receive a virtual channel map and channel name, and only from cable operators. TiVo licenses data
from third parties at its own expense for its guide. OCUR manufacturers like Hauppauge rely on
Microsoft to do the same. Other vendors who license guide data to MVPDs do not even include the
information sought in the Device Proposal.
69
Even VOD data comes with restrictions from rights holders,
such as business and branding rules on search and search returns. The proponents offer no basis for
ignoring these restrictions, only a vague claim to “assure the accuracy” in ways that have been
unnecessary in the market. By contrast, apps that present MVPDs UI delivers all of this as the guide with
the channels in their rightful location with all licensed material.
Content Providers
The Device Proposal does not assure that commercial channels appear in appropriate channel
neighborhoods, that the Content Providers’ brands are displayed in agreed upon locations, that
programs are not overlaid with inappropriate ads, and that distributors respect license conditions that
define permissible and impermissible uses and distribution. Content Providers’ substantial investments
69
For example, Gracenote, DISH’s vendor for rich metadata, “has no plans to implement EIDR.”
DSTAC WG4 Report
August 4, 2015
161
have built valuable and recognizable brands, which they license under carefully crafted arrangements to
preserve their value and provide uniform nationwide presentation through licensed distributors.
Commercial video content providers segment the market based on specific distribution paths, security,
devices, audiences, and advertising opportunities. Content licenses define channel position, tier
placement, acceptable advertising, scope of distribution permitted, security requirements and
consistent presentation of branded content. Content owners license terms govern the geographic area
for delivery, restrictions on copying or redistribution, specifications for how content is displayed,
requirements that particular advertising, branding, polling or other interactive material be associated
with their content, and/or restrict certain types of ads or overlays from being shown with their content.
Content distribution rights have grown far beyond the simple states defined by the CCI bits sent to
CableCARDs. Content providers may specify which devices are trusted and permitted to receive
content. Some content is not available to devices unless they support a hardware root of trust. Content
providers may limit distribution rights to the home, or may place limitations on out of home uses.
Content may be permitted only for defined periods of time, and then erased. Some MVPD distribution
networks distribute all content to set-top boxes, and then rely on the set-top box to limit use to only
permitted geographic areas. License conditions on the devices that receive programming are required to
assure that security and a chain of trust will limit the distribution and use of the content to consumers
and devices that are entitled to receive the programming.
The Device Proposal would also fail to support the interactive features used to enhance programming,
or the advertising models that rely upon audience measurement and audit reports from the devices on
which programming appears.
The Device Proposal fails to support the intellectual property rights underlying copyright licenses and
that provide the incentives for content providers to produce great content, for inventors to create new
methods of distribution and new applications, and for licensed distributors to compete as differentiated
retailers, all to the benefit of consumers.
In addition, by failing to even support rich expression rights that are not enforced through CCI bits or link
protection, the Device Proposal limits deployment of new business models under new rights models.
Such a system is unnecessary since content is readily available in the marketplace over a wide and
growing array of devices and services, including over the Internet. Had such a system been imposed in
2010, it would have harmed consumers, content creators and service providers by mandating a one-
size-fits all approach; ignoring the economic, technological, and competitive realities of the marketplace;
and hindering the development of the myriad content, devices and services consumers enjoy today.
Attempting to impose it again today would have the same result. It would also violate copyright and
contract law, and potentially the First Amendment. Moreover, imposing such a system would impose
costs and obligations on content and service providers that contradict the explicit statutory requirement
that any solution not be "unduly burdensome."
Device Manufacturer
The Device Proposal is designed to “keep the burden of implementation and licensing concerns minimal
to a third party.” It does so in three ways:
First, it assigns the burdens, costs, and losses to service providers, consumers, and content owners.
DSTAC WG4 Report
August 4, 2015
162
Second, it offers no commitment to operate within the actual trust infrastructure. In today’s market,
retail device makers negotiate with the content community over robustness and compliance, and
operate under licenses and business-to-business agreements that assign additional responsibilities and
liabilities. The Device Proposal would abandon this.
Third, it removes third parties from ordinary market dynamics: In today’s market, Google (and others)
pay content providers to include those providers’ content in, for example, YouTube. This has created a
great diversity of video options and experimentation in business models with compensation to content
providers. Program networks and other content providers also enter into direct distribution contracts
with CE device manufacturers (e.g., Apple and Sony), new video distributors (e.g., Netflix, Hulu and
Amazon), non-traditional online packages (e.g., Sling TV), and offer their own apps directly to retail
devices (e.g. HBO Now). This provides the opportunity for device manufacturers who wish to create
their own branded service to receive video service directly from content providers on an appropriately
licensed basis. The Device Proposal would bypass this market by allowing the device manufacture to
create a new retail service from the MVPD retail service, with no compensation to content owners or to
the MVPDs that would be forced to design their networks and invent new support structures.
The amended proposal suggests that MVPD applications are at risk of being withdrawn, citing AT&T’s
sunset of an earlier X-Box app. AT&T continues to provide apps to X-Box.
70
Apps do evolve in response
to changes in the market, as is evident from Google’s sunset of YouTube apps on older devices.
71
However, the evidence demonstrates the continued expansion of MVPD apps in response to consumer
and competitive demands.
Innovation
The FCC has previously acknowledged that regulation in this space “is perilous because regulations have
the potential to stifle growth, innovation, and technical developments at a time when consumer
demands, business plans, and technologies remain unknown, unformed or incomplete,” and that it must
therefore be wary of “fixing into law the current state of technology.”
72
The Device Proposal would do just that. The demands that the proposal would make on MVPDs would
force MVPDs not only to lose the ability to deliver new and improved services to the customers who use
retail devices, but would also force MVPDs to make changes to their overall networks that would impair
their ability to innovate for all customers. Any changes made to any of the three interfaces described by
the Device Proposal have to be coordinated across all MVPDs and retail device manufacturers, and
presumably through regulatory processes. No mechanism has been included for updating supported
codecs.
73
This necessarily slows innovation and advancements in service quality and/or features.
The Device Proposal further states that “Such [protocol based] architectures avoid the necessity to
mandate and test detailed, internal operations of systems.” Although well-written protocols can usually
70
https://support.xbox.com/en-US/xbox-one/apps/att-uverse
71
Google: Certain older YouTube apps will no longer be supported after April 2015,
https://support.google.com/youtube/answer/6098135?p=yt_devicesupport&hl=en&rd=1
72
Commercial Availability of Navigation Devices, CS Docket 97-80, First Report and Order, ¶¶ 15-16 (1998).
73
The amended proposal states that the yet unspecified protocols will be extensible and new features can be
added easily. The decade long transition from IPv4 to IPv6 demonstrates that specifying a protocol does not make
it necessarily readily extensible.
DSTAC WG4 Report
August 4, 2015
163
hide the internal operations of systems, this simplification of real-world experiences has three major
problems, all affecting the means by which interoperability would be maintained and the impact on
innovation.
First, protocol validation and tests for correct implementation of protocols across multiple classes of
devices (servers and clients) has historically proven to be a significant effort involving either massive
coordination and co-location of many companies in an interoperability “plugfest” (e.g. UPnP), or
purpose-built validation test suites that lead to certification (e.g. CableCARD and DLNA validation and
certification). Given the geographic restrictions on many MVPD services, simple independent plugfests
that invite all MVPDs and all likely device manufacturers seem to be impossible. The cost and complexity
of developing and administering test suites for particular protocols is typically managed and paid for by
an organization such as CableLabs or DLNA. The Device Proposal neither identifies nor proposes
formation of such an organization.
Second, when problems are found in either protocols or in specific implementations of protocols,
changes to existing devices and systems are required. Coordination of changes to deployed devices is a
significant task for each MVPD working within its own, entirely managed system. Coordination of
changes across multiple MVPDs with asynchronous update practices, plus across fielded and still-on-the-
shelf devices, plus next-year-model devices is a necessary function where the Device Proposal is silent.
Third, the retail device marketplace is a highly competitive environment. Some devices may be released
with a focus on particular MVPD systems or architectures. If problems are found in a particular retail
device’s protocol implementation after that device is present in significant quantities in the market, the
Device Proposal is silent on how any particular manufacturer should be expected (or required) to
support necessary changes to already-sold and revenue-neutral devices. For example, a retail device
that works across all cable systems but fails to interoperate with the particular features of a DBS
transport stream or IPTV system may be a commercial success, but would not be interoperable or
portable.
Recent history confirms the risk that technology mandates like those in the Device Proposal will rapidly
become obsolete. In 2003, the FCC tried to create a uniform national digital video technology with
CableCARD, but instead the market expanded well beyond cable, then embraced apps and other diverse
solutions. One percent (1%) of today’s 52 million CableCARDs are used in the retail devices for which
they were originally intended. Over its entire 15 year lifespan, there have been only two major changes
in CableCARD—multistream and support for SDV Tuning Adapters. And, even these came with time-
consuming, significant re-engineering and high cost. In 2010, some consumer electronics interests
proposed that the FCC adopt rules for a uniform “AllVid” successor to CableCARD. Had the FCC adopted
the “AllVid” rules, the distributor and programming industries could not have developed today’s
amazing market that provides MVPD programming to smartphones, tablets and other devices embraced
by consumers.
Interposing standards of the sort contemplated by the Device Proposal imposes a significant cost in lost
innovation. There is considerable economic and academic literature documenting that the risks of non-
market failure and the costs to innovation are particular high when the government intervenes in new
markets that are rapidly evolving—such as we have in the converging communications, media, and IT
industries today. Besen and Johnson’s seminal 1986 study concludes: “[T]he government should refrain
DSTAC WG4 Report
August 4, 2015
164
from attempting to mandate or evaluate standards when the technologies themselves are subject to
rapid change.”
74
Premature government standardization reduces competition, experimentation, and creativity, thereby
limiting options for consumers. The need to adhere to a standard limits firms’ product design choices
and ability to invest in new technological approaches. The loss of innovation and variety that can be the
result of standardization is a loss to consumers. If such a government-mandated standard is imposed, it
risks locking consumers into obsolete and/or inferior products. NCTA has previously provided the FCC
with a detailed study of the video devices market by respected economists which explains this very
phenomenon in the video space.
75
MVPDs need flexibility to use diverse solutions that can adapt their particular networks to rapid changes
in technology, competition, cybersecurity needs, energy efficiency, and consumer demand. Effective
service delivery would be paralyzed if FCC waivers were needed every time an MVPD or manufacturer
sought to innovate.
Competition
When Section 629 of the Communications Act was enacted in 1996, almost everyone had to lease a
specific, proprietary set-top box from the cable company to receive digitally-delivered multichannel
programming. Today, cable operators’ share of MVPD customers has eroded over two decades from
98% to 53%. AT&T/DirecTV, Dish, and Verizon are the first, third, and fourth largest MVPDs. Program
networks and other content providers are entering into contracts with CE device manufacturers (e.g.,
Apple and Sony) and other new video distributors (e.g., Netflix, Hulu and Amazon), licensing non-
traditional online packages (e.g., Sling TV), and offering their own apps directly to retail devices (e.g.
HBO Now). Cable and other MVPDs provide customers with multichannel services on millions of tablets,
smartphones, gaming consoles, PCs, Smart TVs and other IP-enabled devices that also access online
video. None of these devices use CableCARDs, relies on FCC technology mandates or follow a uniform
technology.
Video distributors operate as differentiated retailers who implement a variety of technologies, compile
bundles of programming, guides, navigation features, applications and other inputs into distinctive,
branded offerings. Video distributors compete with each other by using different technologies. Verizon
devoted an entire fiber wavelength to its linear video offering and transitioned to all-digital. AT&T
launched its U-verse service designed to maximize its bandwidth for HD and other services. Cable
operators responded with switched digital video (SDV) and DTAs to repurpose analog spectrum and add
more channels, more High Definition, faster broadband, and more innovative services. Features like
instant channel change and multi-room DVR enabled AT&T to better compete against incumbent cable
operators, despite limitations of VDSL networks. Remote Storage DVR enabled Cablevision to compete
against multi-room DVR features. Video providers further compete with each other by adding more
features and creating value and continued consumer recognition of that growing value from their
(branded) service provider. Competition among these retail distributors has fueled and funded
74
“Compatibility Standards, Competition, and Innovation in the Broadcasting Industry,” Stanley Besen and Leland
Johnson, Rand, Prepared for the National Science Foundation, November 1986, at 135.
75
Ex Parte Submission of Economic Analysis of the Regulation of MVPD Navigation Devices in Video Device
Competition Notice of Inquiry (MB Docket No. 10-91, CS Docket No. 97-80, PP Docket No. 00-67), July 19, 2010,
http://apps.fcc.gov/ecfs/document/view?id=7020549667
DSTAC WG4 Report
August 4, 2015
165
competition, innovation, network upgrades, broadband deployment, and consumer choice, and is
helping to drive expanding consumer access to MVPD services on smartphones, tablets, and other retail
devices and platforms. Each innovation by one provider spurs competitive responses by others in the
market. The Device Proposal would strip away the very features and innovations with which MVPDs
compete. Consumers would not even be aware of the enhancements—because the devices will not pass
them through in apps. The Device Proposal would sacrifice the competition that has driven enhanced
services to the benefit of consumers.
The Device Proposal would deny MVPDs the flexibility to innovate while over-the-top video providers
would remain unconstrained in the services they provide. Such an approach is contrary to the
Commission’s well-established policy to
favor a “regulatory regime that is technology and competitively
neutral” and would create a competitive burden on MVPDs contrary to the technology- and platform-
neutrality required by STELAR. Singling out only MVPDs with a different mandate would also create the
same competitive disparities that undermined the cable-centric CableCARD regime.
Conclusion
The Device Proposal concludes that it retains the intended functionality of MVPD service and provides
the same service as MVPD apps. As demonstrated above, it fails on both counts. Instead, it discards
those services and features that do not fit through the stripped-down interfaces and the proposed
architecture of the Device Proposal.
DSTAC WG4 Report
August 4, 2015
166
Evaluation of “Application-Based Service with MVPD UI” (“Apps Approach”) by Proponents of
Application-Based Service
Consumer Experience
The apps approach is based on the successful model developed in the market and widely adopted by
consumers. Consumers are embracing an apps-based way of enjoying MVPD services on their own retail
devices, without the need for an MVPD’s set-top box.
The apps approach enables the delivery of multichannel service that has evolved far beyond simple
broadcast video service and is delivered from a wide variety of video providers using a wide variety of
technologies. Applications support the modern features of MVPD service, such as interactivity,
recommendations from what’s trending, on-screen caller ID, voicemail notifications, and pause/resume
from last point viewed on different devices in the home.
The apps approach also provides the consumer with automatic service and feature upgrades as service
evolves with an app update, as consumers have grown accustomed to on tablets and smartphones.
Application and feature updates are occurring multiple times a month, effected with an application
update.
Applications help to seamlessly integrate software and hardware for a quality consumer experience.
Applications help to seamlessly integrate software and hardware for a quality consumer experience.
Apple’s iPad considerably raised consumers’ expectations of how well hardware and software should
work together. With applications, consumers receive the service as advertised and through a familiar
interface on multiple platforms—TV, tablet, phone, and other video devices. Consumers can enjoy a
common experience on the many devices consumers use to access the service across devices—including
the ability to navigate and see recent tuning history regardless of which device was used—the way it
works with Netflix.
Consumers are guaranteed to receive service as advertised and as intended by the service provider,
including all features. If consumers experience problems, they know where to seek help and who is
responsible for responding to customer complaints.
Enabling service providers to offer their own presentation and remote user interface through an app
permits MVPDs to fulfill the many consumer protections (like statutory privacy requirements) built into
regulated MVPD service. By contrast, there is nothing in a disaggregation approach that prevents a
retail device manufacturer from sharing sensitive viewing information with third parties.
Retail devices that host the application may continue to differentiate themselves with features,
functions, networks, drives, speed, look, feel and price, and may have their own top level user interface,
app store, and menu structure.
Development and Testing
App development work is provided by the service provider for the platform to which the app is directed.
MVPDs, like Netflix, Amazon and other “over the top” video distributers, individually code, test,
improve, and maintain different versions of their apps for the different supported customer-owned
devices and platforms, such as iOS, Android, Mac/OS X, PC/Windows, Xbox, Roku, Kindle, and a variety
DSTAC WG4 Report
August 4, 2015
167
of Smart TVs. Every one of the Top 10 MVPDs offers such apps. Some device manufacturers test against
some of these applications with software changes but the primary burden is on the app developer.
Apps developed for HTML5 are portable, consistent and “write once run anywhere” for all retail devices
that support HTML5.
Apps developed for VidiPath are portable, consistent and “write once run anywhere” for all retail
devices that support VidiPath.
This app development work has been undertaken by MVPDs and OTT providers in response to
demonstrable consumer demand. It has been successful and built upon rather than displaced.
Service Provider
The service provider may update its service and features by updating the app. The new feature set
becomes available through the app. This permits rapid innovation by the service provider. By contrast,
fixed protocols require long timeframes for standardization of APIs or protocols for each new feature,
which is difficult given the variety and pace of change among video providers, technologies, platforms,
services and features. It would take years to develop the hundreds of protocols for use across all
MVPDs,
76
and even then the protocols may not anticipate new services, features, or technologies for
MVPD distribution. Protocols/APIs would also have to be constantly deprecated as technologies evolve.
The apps approach avoids the constraints on service provider innovation that would be a major burden
and cost to the MVPD and to consumers.
A key benefit of the apps approach is its support of the economic fundamentals that have fueled the
growth and development of today’s multichannel ecosystem. Apps give MVPDs the tools to serve retail
devices and assure compliance with their copyright and retransmission consent agreements that define
and segment rights. This is essential to MVPDs’ ability to obtain content from third parties who rely
upon a trusted distribution system. Apps give MVPDs the tools to support the advertising that funds the
dual-revenue MVPD business, and to provide an interactive and accountable ad platform that can
continue to compete for those ad revenues.
Apps give MVPDs the tools to keep enhancing service continuously without awaiting industry consensus,
standards, or rule changes; to create value and consumer recognition of that growing value from their
(branded) service provider; and to help retain them as customers. Apps give MVPDs the tools to
innovate with new technologies, to shape and reshape their offerings to meet changing consumer
demands. Now that there are so many MVPD and OTT providers of video programming, the ongoing
ability to enhance service are critical to an MVPD’s branding and competitiveness. It would be a major
burden and cost to MVPDs and a major loss to consumers if MVPDs were restricted from enhancing
their services and competing. Apps protect against those burdens.
Enabling service providers to offer their own presentation and remote user interface through an app
permits MVPDs to fulfill the many consumer protections (like statutory privacy requirements), “must
carry” rules (like channel position and channel neighborhood), accessibility, and other requirements
built into regulated MVPD service. For example, cable and satellite operators are required to protect the
76
Estimates from among the top 10 MVPDs indicate that the number of protocols or APIs in each of their systems
to deliver the MVPD service range from hundreds to as many as ten thousand.
DSTAC WG4 Report
August 4, 2015
168
privacy of the video records and other personally identifiable information of their video subscribers,
particularly against government intrusion. CE manufacturers are not. Cable operators are required to
restrict the display of commercial web links in association with programming directed to children. A CE
device can overlay prohibited links. Cable operators are required to provide parents the ability to block
channels they consider offensive regardless of rating. CE manufacturers are not. Applications allow
cable operators to send emergency alerts, including force tuning the device. Applications allow cable to
meet channel positioning commitments to local broadcast stations, and to precede changes in channel
position with advance notice. The use of an application based approach permits MVPDs to meet all of
these requirements built into regulated MVPD service.
Enabling service providers to offer their own presentation and remote user interface through an app
permits MVPDs to offer their services consistent with the content licenses and retransmission consent
requirements under which they acquire distribution rights. For example, apps may assure that
programming is kept in the right neighborhood, such as a news channel placed in a news
“neighborhood” or a premium service kept adjacent to its multiplex channels. Apps may assure that
search returns do not place a programmer next to an X-rated offering. If service providers are unable to
effectuate the very arrangements under which they are licensed to distribute secure high value
programming and services, why should they bother to encrypt the service, negotiate distribution
agreements, develop new business models and architect their systems and chains of trust in the first
place? Applications permit the delivery of MVPD services in ways that respect all of these
arrangements.
Enabling service providers to offer their own presentation and remote user interface through an app
also respects service providers’ First Amendment rights to operate as a publisher and the copyright and
intellectual property rights under which video services are licensed and distributed. Apps assure that
channels and services are presented as intended and marketed and that the presentation carries the
content, features, brand, look and feel of the MVPD.
Enabling service providers to offer their own presentation and remote user interface through an app
allows the MVPDs to offer better and consistent support and diagnostics to consumers.
A disaggregation approach would require MVPDs to create new technologies that would separate their
program content from the services they offer so that third parties may reassemble that programming
into their own, unlicensed services. The device maker would have no obligation to present the MVPD
programming with all of its service features intact. The service provider may be unable to provide
consumers with interactive and other enhancements to programming, as well as the future innovations
that do not fit within today’s conception for protocols link-protected or gateway device outputs offering
its service without invoking its user interface, and shut it down. Like Netflix, YouTube now presents its
service through an app and its own user interface.
The apps approach does not permit MVPDs’ services to be reassembled into a different look and feel or
product provided by a device manufacturer, unless there is mutual negotiated agreement. MVPD retail
distributors are not licensed to be wholesale content suppliers to CE device manufacturers to
disassemble the service and create a new service from its components. Content owners license terms
govern the geographic area for delivery, restrictions on copying or redistribution, specifications for how
content is displayed, requirements that particular advertising, branding, polling or other interactive
material be associated with their content, and/or restrict certain types of ads or overlays from being
DSTAC WG4 Report
August 4, 2015
169
shown with their content. Some content providers require that their on-demand programs be grouped
together through a branded entry point (i.e., all shows accessed from a program network-branded
folder). Over-the-top providers such as Netflix use their own application-based UIs and negotiated
business-to-business agreements to enforce these terms on retail devices. MVPDs would be significantly
disadvantaged if they could not enforce applicable license terms when their services are delivered on
retail devices. Without application-level enforcement or negotiated agreements, third party devices
could rearrange channel or program placement, insert different advertising into or on top of programs,
ignore blackout or other geographic restrictions, or use search functionalities to promote illegitimate
content sources over legitimate ones, such that a user about to purchase an on-demand movie might be
directed to a lower-cost pirate option instead. The retail device might also use search functionalities to
promote, or otherwise skew how consumers identify and choose which content to watch (such as
manufacturers charging content sources to improve their search rankings).
Applications can deliver service in several ways to IP-connected devices, including broadband modems
and VidiPath servers. Applications do not compel the redesign of networks to support simulcrypt (a
methodology that enables dual or multiple CAS systems on an MVPD network).
Content Providers
Commercial video content providers segment the market based on specific distribution paths, security,
devices, audiences, and advertising opportunities. Content licenses define channel position, tier
placement, acceptable advertising, scope of distribution permitted, security requirements and
consistent presentation of branded content. Content distribution rights have grown far beyond the
simple states defined by the CCI bits sent to CableCARDs. Content providers may specify which devices
are trusted and permitted to receive content. Some content is not available to devices unless they
support a HW root of trust. Content providers may limit distribution rights to the home, or may place
limitations on out of home uses. Content may be permitted only for defined periods of time, and then
erased. Some MVPD distribution networks distribute all content to set-top boxes, and then rely on the
set-top box to limit use to only permitted geographic areas. License conditions on the devices that
receive programming are required to assure that security and a chain of trust will limit the distribution
and use of the content to consumers and devices that are entitled to receive the programming.
Applications permit MVPDs to enforce these complex and variable arrangements. The intellectual
property rights underlying copyright licenses provide the incentives for content providers to produce
great content, for inventors to create new methods of distribution and new applications, and for
licensed distributors to compete as differentiated retailers, all to the benefit of consumers. Intellectual
property rights support the rich video and distribution environment that consumers enjoy, and need to
be respected. Applications permit MVPDs to operate within these intellectual property rights.
MVPD retail distributors are not licensed to be wholesale content suppliers to CE device manufacturers
who in turn want to present multichannel video service as if it were their own, without responsibility to
programmers or to the MVPD to deliver the content as required by contract. A CE manufacturer, who
likely will have no contractual arrangement with programmers, should not have the ability to present
multichannel video service as if it were its own and without responsibility to programmers and the
MVPD to deliver the content as contracted for by the MVPD.
Program networks and other content providers are entering into direct distribution contracts with CE
device manufacturers (e.g., Apple and Sony), licensing new video distributors (e.g., Netflix, Hulu and
Amazon), licensing non-traditional online packages (e.g., Sling TV), and offering their own apps directly
DSTAC WG4 Report
August 4, 2015
170
to retail devices (e.g. HBO Now). This provides the opportunity for device manufacturers who wish to
create their own branded service to receive video service directly from content providers on an
appropriately licensed basis.
Device Manufacturer
Applications permit MVPDs to bring more devices into the distribution system. For example, an
application may deliver standard definition content to devices that lack a hardware root of trust, rather
than denying all content. The apps approach has radically expanded the number of video devices on
which consumers can enjoy their MVPD services, far more quickly than any regulatory approach.
With an apps approach, the retail device can have its own distinctive top-level interface, app store, and
menu structure, and can also differentiate itself with features, functions, look and feel, networks, drives,
speed and price. Regardless of MVPD and other apps presented, Android & iOS compete vigorously in
user interface; Nintendo, PlayStation, and XBOX have competitive user interfaces; LG, Panasonic,
Samsung, Sony, and Vizio compete in user interface. All allow MVPD apps to present MVPD service as
offered and branded by the MVPD. The different video apps all appear as selectable apps that, once
clicked, present the retail experience of that video provider in the manner selected by that provider.
Apps reduce the burden on CE to map to multiple network technologies and CAS trust infrastructures.
The CE manufacturer can expose distinctive resources of the device to app developers, such as multi-
touch and speech recognition. The CE manufacturer can also continue to innovate in its devices without
the constraints of fixed protocols. For HTML5-based models, all the CE manufacturer has to support is a
common HTML5 browser or interface.
Retail devices are clearly succeeding under this apps model. As noted above, Roku has sold over 5
million units, relying entirely on apps (including a cable-operator supplied guide), outselling TiVo (with
its “third party” TiVo guide) ten-to-one. No evidence has been presented to the DSTAC to indicate that
retail devices needs to interfere with the retail relationship between an MVPD and its customers to
distinguish themselves.
Consumers should be able to buy devices with different capabilities, but the devices need to meet
content provider requirements, enable the MVPD to present services as intended and advertised, and
enable the MVPD to continue to innovate and compete. See Report of WG1, MVPD Requirements and
Content Providers Requirements [76]. The [Disaggregated Protocols System model proposed by Brad
Love] would not meet these fundamental requirements. There is no need to dumb down MVPD service
or strip out features in order to serve a variety of retail devices. For example, MVPDs and content
providers already support the highly successful smart phone and tablet market by using a variety of apps
tailored to their iOS or Android platforms. When consumers chose a smart phone, they understand that
their services are delivered through applications created for that platform, not through a uniform
regulatory protocol. Consumers may also chose a feature phone, but they understand that they may
not receive MVPD services on those devices, because feature phones are not designed with the
resources and platform necessary to render the services that MVPDs offer. No video app developer is
compelled to deprecate its service to appear on a feature phone. Likewise, there should be no
requirement that modern MVPD service be dumbed down for reception on a supposedly smart video
device, when applications can present the MVPD service as offered.
DSTAC WG4 Report
August 4, 2015
171
Innovation
The CableCARD model adopted more than a decade ago was designed only for reception of one-way
linear cable channels from digital cable systems, and required retail CableCARD devices to use their own
guides. This approach reflected basic technical limitations at the time – a one-way device could not
support interactive services or the cable program guide, and suitable remote user interface technology
did not exist. The protocols in use for CableCARD were designed only for non-interactive linear channels
on cable systems. The resulting devices met with very little consumer acceptance.
Much has changed in the past decade. Multichannel service is no longer a simple broadcast video
service, but a complex interaction of licensed content, network, security, content protection, hardware,
software, licensed metadata, diagnostics, application data synchronized with content, UI, advertising, ad
reporting, audit paths, etc. The technology varies across platforms and changes continuously without
awaiting industry consensus, standards, or rule changes. Apps allows delivery of this service to a wide
variety of CE devices and platforms, none of which are built to a common standard. Reducing MVPD
service to unimproved broadcast channels sacrifices decades of improvement and frustrates the
continued innovation among competing MVPDs that keeps driving more innovation.
Like MVPD services, today’s market has also changed considerably from the environment in which
CableCARD was created. When Section 629 of the Communications Act was enacted in 1996, almost
everyone had to lease a specific, proprietary set-top box from the cable company to receive digitally-
delivered multichannel programming. Today, cable operators’ share of MVPD customers has eroded
over two decades from 98% to 53%, and DBS and telephone companies are the second, third, fifth and
sixth largest MVPDs. Program networks and other content providers are entering into contracts with CE
device manufacturers (e.g., Apple and Sony) and other new video distributors (e.g., Netflix, Hulu and
Amazon), licensing non-traditional online packages (e.g., Sling TV), and offering their own apps directly
to retail devices (e.g. HBO Now).
77
Cable and other MVPDs provide customers with multichannel
services on millions of tablets, smartphones, gaming consoles, PCs, smart TVs and other IP-enabled
devices that also access online video. None of these devices use CableCARDs, relies on FCC technology
mandates or follow a uniform technology. The FCC need not “create” an IP successor to CableCARD; the
retail marketplace today has created unprecedented and growing choices for multichannel content and
online content, eliminating the need to pursue a regulatory route.
Consumer demand varies and evolves, and competitors have the right to innovate with new
technologies, to add value-added services, to shape and reshape their offerings to meet changing
consumer demands. Diversity and an apps approach enables MVPDs to enhance their networks over
time to increase network capabilities, such as increased capacity, device addressability, security,
reliability, energy efficiency, quality of service, and operational efficiency. Application and feature
updates are occurring multiple times a month, effected with an application update. The changes do not
await agreement on a new protocol or standard. Applications allow the MVPD to advertise and
promote these new features through their applications. Diversity and an apps approach also enables
MVPDs to retire obsolete networking technologies as necessary to achieve these enhancements.
77
The amended proposal inexplicably describes DOCSIS cable modems as “outdated technology.” DOCSIS and
DOCSIS modems are the foundation of the infrastructure that has enabled the distribution of online video and the
modern broadband economy.
DSTAC WG4 Report
August 4, 2015
172
Competition
The apps approach has been developed in the marketplace through competitive responses to consumer
behavior and preferences. The app model builds upon existing standards and solutions developed to
deliver rapidly changing services to varied and rapidly changing consumer electronics devices and
platforms. It has been widely and successfully adopted by consumer electronics manufacturers, MVPDs
and OTT video service providers such as Netflix and Amazon. The apps approach leverages technological
advancement and the development work in Internet (W3C) HTML5, DLNA, iOS, and Android. It enables
the delivery of multichannel service that has evolved far beyond simple broadcast video service and is
delivered from a wide variety of video providers using a wide variety technologies to a wide variety of
consumer devices.
The apps approach preserves innovation and competition by MVPD and OTT video providers. Apps
permit service providers to innovate with new technologies, to add value-added services, and to shape
and reshape their offerings to meet changing consumer demands with a code update. It does not
require long timeframes for invention and standardization of APIs, protocols, or modules for each new
feature.
The apps approach promotes competition in the manner intended by Section 629. Video distributors
operate as differentiated retailers who compile bundles of programming, guides, navigation features,
applications and other inputs into distinctive, branded offerings. Video providers compete with each
other by adding more features and creating value and continued consumer recognition of that growing
value from their (branded) service provider. Competition among these retail distributors has fueled and
funded competition, innovation, network upgrades, broadband deployment, and consumer choice, and
is helping to drive expanding consumer access to MVPD services on smartphones, tablets, and other
retail devices and platforms. DISH launched its commercial DVR in 1999; DirecTV and cable operators
soon followed. Subsequent innovations by one MVPD lead others to match or better their offerings:
multiple tuners; high definition tuners; remote scheduling of DVRs; multi-room DVRs; video-on-demand
libraries; StartOver; interactive program guides; t-commerce; voting, polling and other interactive and
cross-platform services like Caller ID on TV. Each innovation by one provider spurs competitive
responses by others in the market.
This continuous change reflects innovation without permission, and without awaiting industry
consensus or standards. New MVPDs developed new networks and services that do not conform to a
standard. Verizon devoted an entire fiber wavelength to its linear video offering and transitioned to all-
digital. AT&T launched its all-digital U-verse service with all channels switched to maximize its
bandwidth for HD and other services. Cable operators responded with switched digital video (SDV) and
DTAs to repurpose analog spectrum and add more channels, more High Definition, faster broadband,
and more innovative services. As MVPDs innovate and compete, consumers are the ultimate winners.
Regulation, fixed protocols, and technology mandates constrain this competition. Section 629 is directed
to equipment used to access services offered by MVPDs over multichannel systems, not to promote
services provided by third parties and created from disaggregated components. Reducing competition
among MVPDs would be a major burden and cost to MVPDs and to consumers.
MVPDs are not seeking to prevent competition from CE manufacturers. They are supporting many more
retail devices than they are their own set-top boxes, and continue to expand service to more devices.
The Top 10 MVPDs have all used applications to enable an ever-expanding set of customer-owned
devices to receive their services. Unlike the Bell System that sought to prevent competition to its wholly-
DSTAC WG4 Report
August 4, 2015
173
owned Western Electric equipment division, cable operators, Verizon, AT&T and DirecTV do not own
any of their set-top box vendors. They are supplied by a growing number of consumer electronics
manufacturers (including TiVo). Cable operators now constitute TiVo’s fastest growing market, and
comprise approximately 80% of TiVo’s customers. An applications-based approach promotes
competition by CE manufacturers.
An apps approach is also consistent with the approach used by OTT video providers. Singling out only
MVPDs with a different mandate will create the same competitive disparities which undermined the
cable-centric CableCARD regime, and would create a competitive burden on MVPDs contrary to the
technology- and platform-neutrality required by STELAR. The apps approach also permits device
manufacturers and platforms to continue to innovate and compete with one another. The retail device
may present (and continuously improve) its own interface, environment and user experience. The
device presents a selection of available applications from multiple MVPDs and OTT video providers that
can operate as retail stores presenting their own brands and experiences. This apps approach preserves
the “chain of trust” from the content supplier to the distributor to the consumer, respects the license
restrictions on the content, and preserves the subscription and advertising ecosystem which funds these
services and the networks that deliver them.
DSTAC WG4 Report
August 4, 2015
174
Passage to Facilitate Transition to All DRM Approach
Sony's Passage
™
technology is a simple, elegant solution that allows multiple security systems to co-exist
on legacy digital CATV networks. It is suitable for broadcast linear streams where a service provider
supports simultaneous distribution to receivers with legacy Conditional Access (CA) and new security
such as Digital Rights Management (DRM).
Passage technology use of selective multiple encryption (SME) is based on a fundamental understanding
of MPEG compression and how compression may be used as a form of encryption. Not all of the
content needs to be scrambled by the security system – only that which is needed to decompress the
rest of the content. Most of the compressed, hard-to-recover, content can be sent in-the-clear!
Passage facilitates a transition to an all DRM system where a DRM may be loaded into client devices and
use the standardized HTML 5 Encrypted Media Extension (EME) abstraction layer. Use of DRM can also
be compatible with the RVU and VidiPath proposals. The same DRM system used to encrypt the
MVPD’s web services may be used to encrypt linear content. And this can facilitate delivery of
entitlements to client devices that comprehensively covers both linear and web content, instead of
supporting parallel security systems - legacy CAS, for linear content, and DRM, for web services. All of
the content could be delivered and managed using DRM (with support for legacy CAS with linear
content).
Passage is efficient. With Passage technology, the customer experiences no degradation of existing
services. A typical Passage system requires between .2-2% additional bandwidth to deliver the same
content and services including the new, second security system. This means that Passage can be
introduced in a system without changes to the existing channel line-up.
As shown in Figure 41, End-to-End DRM can facilitate the reception of linear content either through
direct-attach or network attach means. It enables a larger number of devices, especially smaller form-
factor mobile ones, to receive content that would otherwise be reserved for set-top boxes. If a gateway
is assumed, content may be transcripted from DRM to DTCP link protection or pass-through AS IS with
DRM encryption to home network devices. Persistent DRM control may allow for a wider variety of use
cases that could be otherwise permitted using Copy Control Information (CCI) bits delivered with DTCP
or across the CableCARD interface using DFAST.
DSTAC WG4 Report
August 4, 2015
175
Figure 41- Use of Passage to Enable End-to-End DRM
Implementation
Passage is proven technology. There have been a number of field and lab trials as well as deployments
with the Cisco CA Overlay system. A description of the steps needed to Passage encode a stream is
described in Part II of this document.
The best way to deploy Passage is at the point of commercial distribution. All the MVPD receive their
content one of 3 ways – Broadband/Satellite delivery, Programmer delivery, or locally. If the
companies, offering Broadband/Satellite delivery or Programmer delivery, Passage encoded their
commercial streams, MVPDs downstream would not require any new equipment. A stream would be
processed in one place, and then distributed throughout the US. There are 4 or 5 different headend
configurations and they all can be accommodated by reconfiguring their existing equipment. And non-
participating headends, perhaps exempted from any FCC regulation, won’t need to opt-out - they won’t
need to do anything. Participating headends will only require normal functions of existing equipment –
stream groomers and multiplexers - with normal features such PID filtering, PID remapping, and
descrambling and re-scrambling. Local content is the only content that would require local Passage
encoding.
Passage hardware components are implemented in both the headend and in every Passage-enabled set-
top box, with the latter available from a variety of participating manufacturers. The following
components are implemented as part of the Passage-enabled system.
Headend encoder
DSTAC WG4 Report
August 4, 2015
176
Device (decoder)
Alternate security system encryption
Contact Information
E-mail: Brant.Candel[email protected]om
DSTAC WG4 Report
August 4, 2015
177
Policy Analysis by Content Providers
Many members of the DSTAC continue to object to the scope of certain aspects of this report. Congress
created the DSTAC to examine downloadable security systems. Indeed, as highlighted in a June 18 letter
from Reps. Latta and Green to Chairman Wheeler, section 106(d) of STELAR gave the working group nine
months from enactment "to identify, report, and recommend performance objectives, technical
capabilities, and technical standards of a not unduly burdensome, uniform, and technology- and
platform-neutral software-based downloadable security system designed to promote the competitive
availability of navigation devices in furtherance of section 629 of the Communications Act of 1934.”
Some parties would like the DSTAC to go beyond its statutory mandate and design a system that forces
video providers to allow third-parties to disassemble the programming, features, and functions of the
video service so that the third-parties can selectively reassemble parts of them for their own commercial
exploitation.
This is similar to the 2010 “AllVid” proposal the FCC abandoned in the face of widespread opposition by
content creators; cable, satellite, and IPTV distributors; and others. Such a system is unnecessary since
content is readily available in the marketplace over a wide and growing array of devices and services,
including over the Internet. Had such a system been imposed in 2010, it would have harmed consumers,
content creators and service providers by mandating a one-size-fits all approach; ignoring the economic,
technological, and competitive realities of the marketplace; and hindering the development of the
myriad content, devices and services consumers enjoy today. Attempting to impose it again today would
have the same result. It would also violate copyright and contract law, and potentially the First
Amendment. Moreover, imposing such a system would impose costs and obligations on content and
service providers that contradict the explicit statutory requirement that any solution not be "unduly
burdensome."
We participate, nonetheless, in the hopes of fulfilling the DSTAC's actual mission of promoting a
downloadable security system; to protect the interests of consumers, content creators, and service
providers from those who wish to disaggregate content, features, and functions for their own pecuniary
gain; to ensure the report reflects our statutory, policy, and legal concerns over the AllVid-type
proposals; and to make sure that any such proposals at least provide consumers access to all the
features and functions currently available. If parties wish to offer a narrow or specialized subset of
features and functions, they should do so through individualized negotiations in the marketplace, not
through regulatory fiat.
Summary of Objections Stated Within the Policy Analysis
Our overall objections are that: 1) the working group assignment goes beyond the DSTAC statutory
mandate, 2) that the marketplace for MVPD and OTT services is flourishing, calling into question the
need to impose an AllVid like mandate, 3) that doing so will harm consumers, content creators, and
service providers, and 4) that some of the proposals would violate copyright and contract law.
DSTAC WG4 Report
August 4, 2015
178
Evaluation of Both Proposals by Proponents of “Competitive Navigation” Proposal
Fundamentally, the “MVPD” App proposal does not allow for a competitive user interface and, instead,
seeks to lock consumers into having an operator-mandated user interface as the only way to discover,
browse, select, record and view content. No resource is made available to a third party device to
perform such functions. Hence no competitor can field a device that is comparable to the operator’s
own. This is anathema to the entire purpose of Section 629 of the Communications Act, which is to
assure that there is a market for competitive navigation devices.
78
As described in the Response to Evaluation of CE Device Competitive Navigation System Proposal by
Proponents of Application-Based Service, the “MVPD” app approach not only forecloses use of a
competitive interface; it also locks in the status quo of operator control by eliminating the degree of
interoperability and choice assured by the CableCARD interface, impaired as it has been by existing
licenses, contractual restrictions, and failures to update the technology. Unlike CableCARD, the
interfaces required by the MVPD App proposal offer to consumers none of these assurances:
● An assurance that her device will be authorized by the operator for their mandated user
interface. The MVPD can withdraw support for the app for any reason at any time.
79
● An assurance that her device will operate portably across similar systems.
● An assurance that her personal recordings, viewing preferences, account associations, parental
control settings and other components of the user experience will be portable across operators.
Because the MVPD owns the entire experience, all of these preferences remain in the control of
the MVPD.
● An assurance that recommendations are according to her personal preferences rather than the
MVPD’s economic interest. Only an competitive third party user experience has the ability to
work independently of the economic interests that content owners can enforce on MVPDs with
respect to promotions through “recommendations.”
● An assurance that there will ever be an “app” that will work interoperably across systems.
Rather, operators will be assured that devices do not become an instrument to empower
consumers to choose among MVPD offers on a competitive basis.
78
Consumers’ desire for better alternatives to MVPD supplied interfaces is well established. See, e.g., John Patrick
Pullen, America’s Most Hated Device: The Cable Box, Aug. 27, 2013, at
http://tech.fortune.cnn.com/2013/08/27/americas-most-hated-device-cable-box/. The limitations on
competition inherent in the MVPD App proposal can only enlarge and entrench this circumstance.
79
AT&T U-verse had advertised its app on X-Box as an inducement for customers to sign-up for its service and later
abruptly announced that it would terminate support for its app on the Xbox 360 service. See Jeff Baumgartner,
AT&T U-verse TV To Drop Support For Xbox 360 on December 31, Nov. 26, 2013, at
http://www.multichannel.com/distribution/att-u-verse-tv-drop-support-xbox-360-december-31/146904.
DSTAC WG4 Report
August 4, 2015
179
A Comparison of WG4 Proposed Systems
Two systems have been proposed in Part III of this document, each highlighting issues that should be
addressed and appropriately balanced in the distribution of paid video programming with and without
competitive retail navigation devices.
These system proposals emphasize, and are consistent on, several key points:
● Content should be protected against piracy and other illegal uses.
○ As such, detailed content usage restrictions (e.g. CCI) should be appropriately addressed
or addressable via given systems without unduly restricting end-user consumption
capabilities.
● Various operator network technologies must be abstracted and uniformly addressable via these
systems, including unidirectional distribution networks (e.g. Satellite).
● Because formats and network architectures are evolving, systems and protocols should be
tolerant to changes in delivery networks to provide service continuity and consumer confidence
in retail device compatibility.
● Basic metadata for navigation is fundamental to network-based experiments
● Rich metadata, either from the MVPD or at least with the ability to align with independently-
sourced rich metadata is critical to enabling modern content consumption experiences.
● Regulatory concerns (e.g. EAS) must be considered.
● Commercial considerations (e.g. billing notification) should be addressed, where possible.
Though the two proposals differ on elements such as enabling choice in competitive user interfaces,
large elements of the proposed systems align architecturally. As described below however, where the
systems differ manifests in the user experiences allowed due to design elements controlling capabilities
independent of downloadable content security.
Description of Part III Section I proposal
Part III: Section I describes a “Competitive Navigation” System enabling competitive navigation devices
with access to MVPD content. This system emphasizes necessary structural elements within a “Provider
Interface”, and it focuses on description of the elements necessary for an Internet-Protocol-backed
protocol-based interoperable mechanism.
In particular it describes three extensible interfaces, based on Internet standards, called the Service
Discovery Interface, the Content Delivery Interface, and the Entitlement Information Interface. These
Provider Interfaces could be offered by each MVPD alongside their own application based solution. The
interfaces provide the following to competitive navigation devices over the user’s home network:
● information on video services available to the consumer and devices
● access to content over a common network interface
● entitlement and usage rights information of the available services
DSTAC WG4 Report
August 4, 2015
180
Description of Part III Section II proposal
Part III: Section II. describes an “Application-Based Service with Operator Provided User-Interface”
System. This proposal suggests the implementation of six sub-proposals consisting of existing
technology. The most obvious common feature of these sub-proposals is the requirement of control of
the navigation user interface by MVPDs, even on competitive devices.
The sub-proposals highlighted in the Part III Section II proposal are:
● An application framework for Device Specific Apps (e.g. iOS, Android, Samsung Smart TV, LG
WebOS, Xbox, PlayStation, Roku)
● HTML5 Web Browser that may support MVPD Apps
● DLNA VidiPath Client platform (but not allowed to be server with independent UI for MVPD
services)
● RVU Client platform
● DISH Virtual Joey
● Sling Media Technology Clients
The first, use of Device Specific Apps, is naturally open-ended, but will be discussed below.
Two more of these, DISH Virtual Joey and Sling Media Technology Clients, are closed and proprietary,
providing difficulty in technical analysis and, by definition, competitive interoperability. Nonetheless,
elements of their design will be discussed
The remaining three sub-proposals (HTML5 Web Browser, DLNA VidiPath, and RVU Client) are similar in
their approaches to user-interface presentation (i.e. operator controlled HTML) but vary in downstream
link protection and network topology.
Evaluation of CE Device “Competitive Navigation” System Proposal
Unlike the MVPD UI Application-Based Service proposal, the CE Device “Competitive Navigation” System
Proposal (henceforth the “Competitive” proposal) offers consumers choice in competitive user
navigation experiences. It enables a competitive landscape by allowing both an MVPD UI Application,
and a competitive alternative UI option to consumers. Without this choice, consumers would have
nothing more than the current status quo of a fragmented MVPD application space, where some MVPDs
offer applications on some devices, without the advantage of a competitive UI option that CableCARD
provides. If a reduction in the status quo were sufficient, Congress would not have directed the FCC to
establish the DSTAC and would have repealed Section 629.
While the MVPD UI proposal mandates only the MVPD’s UI via their proprietary application, the
competitive proposal provides an alternative option, which meets the requirements for competitive
navigation devices. The Competitive proposal does not prohibit competitive app-based solutions from
the MVPD directly, thus giving consumers both options.
The Competitive proposal identifies a system comprising minimum standards, protocols, and
information to enable competitive availability of devices that receive MVPD services in accordance with
DSTAC WG4 Report
August 4, 2015
181
Section 629 of the Communications Act. The “MVPD” app proposal, by contrast, does not afford
competitive availability of devices as that goal has been understood to date, and would lock consumers
into having their video consumption experience framed and controlled entirely by the MVPD. That
proposal provides for an operator-mandated user interface as the only way to discover, browse, select,
record and view content. The navigation device is given no resource to perform those functions on its
own, and therefore by definition is not a competitive navigation device compared to one provided by
the MVPD themselves.
The premises upon which a competitive environment for navigation devices and user interfaces can and
should rest are:
● A recommendation for the identification and development of standards to further the objectives
of Section 629 need neither limit nor rely upon the existence and development of any MVPD-
provided UI. Hence, the Competitive proposal, while not conceding that an MVPD’s UI is
“integral to the service,” does not rule out its availability to a user in a device with a competitive
UI.
● Nothing in legislation, FCC regulation, or market practice today refers to an MVPD’s suite of
programming and services as an indivisible bundle, aggregate, or “service.” The “MVPD” analysis
recognizes this in portions in which it refers to MVPD support for “apps” that provide partial or
limited access to MVPD offerings.
● Nothing in the Competitive proposal addresses whether FCC regulations would or would not
require, e.g., the numbering, grouping or presentation of channels, or other matters of concern
to an MVPD and / or content provider. The proposal is made in the context of a TAC process and
DSTAC recommendation of “performance objectives, technical capabilities, and technical
standards … to promote the competitive availability of navigation devices ….”
● That the ability of a consumer to choose among MVPDs, geographically or on a competitive
basis, will be a consideration for the Commission in evaluating DSTAC recommendations.
The history of innovation in this space, however, shows the advantage of a competitive enabler like
CableCARD: The significant innovations in empowering consumers with abilities to control access to
content have come from third parties. The success of these third party innovations has been constrained
only, and significantly, by an ongoing inability to effectively integrate them with MVPD programming
and services on any competitive basis. Innovation thus has occurred despite, rather than because of,
MVPD initiative. Consumers will gain, not lose, from an environment in which such innovation is enabled
rather than frustrated. Examples:
DVR – Pioneered by ReplayTV and Tivo with products launched in 1999, this is one of the most widely
loved technologies by consumers and was truly innovative. This was a technology developed by third
parties, with no involvement from MVPDs. This third party innovation became fundamental to every
MVPD’s conception of its “service,” yet owes nothing to any concept or application of service
“aggregation.” The only “disaggregation” that occurred was when MVPDs moved to HDTV transmission
without providing for competitive access to the digital program stream, until obliged by legislation and
regulation to offer the CableCARD interface.
DSTAC WG4 Report
August 4, 2015
182
Whole Home Media w/ DVR – Pioneered by SageTV and integrated into its products in 2003; this was
the first product that afforded user access to all household media content, including DVR recordings
from any TV. This technology was built on top of a PC platform without any involvement from MVPDs.
Similar technologies are now standard in most MVPDs systems, as many have evolved to a client/server
model with DVR storage all occurring on a central device in the home and client devices existing at the
TVs. This third party innovation is a parent of VidiPath, RVU and other ‘gateway’ approaches now
purportedly “integral” to MVPD “services.” VidiPath employs a technology similar to the SageTV Client
solution released in 2003; RVU employs a technology similar to the SageTV Media Extender technology
released in 2005.
Remote Viewing – Pioneered by Slingbox in 2005; the first to allow users to view live TV and DVR
content from anywhere they choose. It freed viewers from having to be at home to see their content,
and allowed them to stream it to parts of the home away from the main set top box (before MVPDs
starting offering whole home media solutions). This technology was extended to support smart phone
and tablets once those became available in the consumer market. This third party innovation is now also
said to be “integral” to an MVPD’s “service” if (and only if) provided via the MVPD’s UI or a licensed app.
Remote DVR Management – Released by SageTV in 2005 as a webserver plugin for SageTV Media
Center; this innovation allowed consumers to schedule recordings from anywhere at any time, through
the use of a web browser (which became even more accessible with the advent of smart phones &
tablets). Again, this was built on top of a 3rd party system that integrated on top of the essential MVPD
video services with no assistance from MVPDs. This innovation is now a standard feature in many of the
MVPD ‘apps’.
Not every third party innovation is successful or available to consumers, because they cannot be
integrated into an MVPD service on a competitive basis. A vast number of innovations remain
unavailable to most consumers (e.g., plugins for products like MythTV, SageTV, MediaPortal, XBMC,
etc.). The main reason for this is the lack of the ability to make a product that can actually do well in the
retail market. Currently, it is impossible to make any kind of cost effective retail device that
interoperates in an HDTV environment with all the different MVPD service offerings. Implementation of
the Competitive Navigation Device proposal would allow such innovations to reach a competitive
market. Shutting the door on such innovation would put an end to it.
While CableCARDs were limited to one-way function by MVPDs as a license condition
80
rather than a
technical requirement, and were hampered by poor support from Cable operators
81
, the competitive
80
The cable industry itself promoted and licensed a “tru2-way” implementation relying on the same CableCARDs,
purportedly to support competitive devices but saddled with additional license restrictions
81
Criticism of the extent and quality of cable industry support for CableCARD-reliant retail devices has been
repeatedly acknowledged in FCC and judicial records, including by the FCC itself and the Court of Appeals. See, e.g.,
In the Matter of Implementation of Section 304 of the Telecommunications Act of 1996, Commercial Availability of
Navigation Devices, CS Dkt. No. 97-80, Second Report and Order ¶ 39 & n.162 (Mar. 17, 2005); Federal
DSTAC WG4 Report
August 4, 2015
183
proposal would enable third party devices and unique user interfaces to present two-way services.
Despite baseless assertions that competitive guides were always meant to be “transitional” features or
that CableCards (hence all competitive devices) were designed as inherently “one way,” the Competitive
proposal enables the intent to create a competitive market for two-way navigation devices. Such devices
will have access to the services the customer has paid for, including traditional services such as linear
television, Video On Demand, and Pay Per View, and new services such as “cloud” DVR and out-of-home
viewing. Separating the MVPD user interface from these services will foster innovation in their usage,
just as CableCARD devices brought several new innovations to Cable.
The MVPD UI proposal also appears to be limited to existing standards and tries to define application
environments which do not meet all of the requirements of a future looking solution. Being limited to
existing standards could freeze innovation into those existing standards. There is no reason to cabin
DSTAC recommendations so as to reflect only the status quo. The references to technical standards in
FCC regulations have accounted for progress as reflected in standards, and can so account when
recommendations are reflected in references. The Competitive proposal includes extensible protocols
that allow both MVPDs and Competitive device manufactures to add new features without having to do
the difficult task of changing the application environment. There is no requirement or even
recommendation for an application execution environment. On the contrary, the competitive proposal
points out that previous application execution environments for pay television such as OCAP [23] and
DVB-MHP [22] were failures because of both the technical complexity and competitive restrictions they
placed on navigation devices.
Additionally, the Competitive proposal gives the consumer the ability to (1) move a purchased device to
a territory served by another cable operator, or (2) choose to change MVPD providers, or to access
video programming and services from more than one provider. The MVPD UI proposal, by contrast,
could remove this consumer benefit as enjoyed by CableCARD device purchasers today. Unlike with
CableCARD, under the MVPD proposal the consumer gets none of the following assurances in her
decision to purchase a navigation device instead of obtaining one directly from the MVPD:
● An assurance that her device will be authorized by the operator for their mandated user
interface. The MVPD can withdraw support for the app for any reason at any time.
● An assurance that her device will be portable across operators.
● An assurance that her personal recordings, viewing preferences, account associations, parental
control settings and other components of the user experience on the device will be portable
across operators. Because the MVPD owns the entire experience, all of these preferences
remain in the control of the MVPD.
Communications Commission, Connecting America: The National Broadband Plan § 4.2 at 52“ ([C]onsumers who
buy retail set-top boxes can encounter more installation and support costs and hassles than those who lease set-
top boxes from their cable operators.”); Charter Communications v. FCC, 460 F.3d 31, 40-44 & n.10 (D.C. Cir.
2006).
DSTAC WG4 Report
August 4, 2015
184
● An assurance that recommendations are in her personal preferences rather than the MVPD’s
economic interest. Only an independent, third party user experience has the ability to work
independently of the economic interests that content owners can enforce on MVPDs with
respect to promotions through “recommendations.”
The Competitive proposal leverages the existing dominant usage of HTTP as the modern method for
delivering uni-cast video content. YouTube, Apple TV, Netflix, Sling.tv and millions of other content
platforms on the Internet use HTTP as transport of video and metadata and not web pages and web
apps. It does not relay on outdated technology such as silicon key ladders, DOSCIS cable modems, low-
noise block downconverters (LNB), etc.
Like the CableCARD specification, the Competitive proposal defines protocols but intentionally leaves
implementation details of navigation up to the implementer. This is consistent with many layer
protocols that define Internet web services. For example Hypertext and hyperlinks, the basis for modern
web browsing, are intentionally defined separately from the browser or other technology that navigates
them to allow both sides of the interface to be flexible. Defining implementation like in an App-only
approach would limit both the cable operator and the device manufacturer.
The competitive model describes a Man Machine Interface (MMI) that does offer a predictive execution
environment for the MVPD to create “widgets” that may be needed for implementation of certain
features (such as PPV/VOD purchasing, VOD playback including LookBack and StartOver, service
upgrades, billing, support relating to the MVPDs service, caller ID, sports scores, etc.) without requiring
the added complexity of requiring an execution environment for content delivery. HTML5 with various
extensions is clearly a choice many parties are agreeing on for user interaction (as opposed to the
prevalent use of HTTP and not HTML5 for content delivery). While the consumer could choose to use a
MVPD provided app that reflects the entire MVPD UI (similar to VidiPath), in order to enable
competitive navigation UIs they would simply also need to offer subsets of that same UI that reflect the
various widget components mentioned above.
The competitive proposal strikes the proper balance of implementing an execution environment for
what it is good at, without requiring it for access to content, and therefore restricting or preventing a
competitive UI. Through this correct balanced use of an execution environment, competitive devices
would have the freedom to innovate on the UI and then utilize the widgets in the contexts where they
are needed to interface with the particulars of a given MVPDs service. Mandating an execution
environment for the MVPD application as the only platform for access to service would only limit
innovation and the marketplace.
The basis of competition is differentiation and choice. Not every feature available from one product
would be available in every competitor. The market will decide which set of features it prefers. The
MVPD UI proposal does not give the user a choice in the feature set. The Competitive model allows the
MVPD to enable features in both their own application and in the competitive interface if they choose.
For example in their presentations operators listed several features that are part of their user interface
application. U-Verse noted it has implemented fast channel change within its application. In the
DSTAC WG4 Report
August 4, 2015
185
competitive proposal U-Verse can also offer that service in its implementation of the Content Delivery
Interface; U-Verse would implement fast channel change in the interface itself. The competitive device
would request a channel, and the U-Verse interface implementation would perform whatever
proprietary protocol is required for fast channel change. U-Verse would do the same in a VidiPath or
App-model approach. In both proposals the receiving device does not implement fast channel change,
but it is still available to all navigation devices. The same applies to features such as advertising
insertion, telescoped ads, switched digital channels, and many more that are network or system specific
features. In addition, the abstraction (not stripping as claimed) from network specific technologies that
both proposals use gives MVPDs more freedom to make changes to their network technologies.
Vidipath clients, for example, would make the same request for a channel change regardless of how U-
Verse implements fast channel change. If they change that technology, the clients would not need to
change.
Additional features maybe not thought of yet could be covered by the HTML5 widget model in the MMI
explained above. The competitive proposal included interactive enhancements and MVPD-unique
elements via the MMI. Interactive enhancements from the MVPD can easily be achieved by the MMI
widget model. Beyond that, the implementer’s competitive navigation devices will be able to create
their own interactive enhancements that to date have lacked any vehicle for delivery to consumers.
Final specifications may include methodologies for phasing out obsolete technologies over time and use
extensible technologies for expansion of future capabilities.
As noted, the Competitive proposal describes interfaces based on extensible web protocols, the basis for
most Internet services which have proven they support rapid innovation. In the competitive proposal
services can be enhanced and new ones added without constraining the client device into running a
complete MVPD UI. Extensible protocols such as XML allow client devices to ignore elements they don’t
support (or choose not to support) and thus new features can be added easily. The Internet has been
built on such extensible technologies. The standards, protocols, APIs, and interfaces that will eventually
be finalized for allowing creation of a competitive navigation device should also include extensible
technologies as well where relevant.
While the MVPD UI proposal lists many different DRM and copy protection systems, without indicating
which would guarantee access to content, the Competitive proposal recommends DTCP-2 which is in
development and would satisfy both the CCI and format requirements of modern business models.
Consumer device manufactures that implement and meet the licensing requirements of DTLA would
have assurance that their devices would be able to receive encrypted content.
The competitive proposal includes content protection models similar to the content distribution and
DRM/CAS solutions presented in the MVPDs App model proposal. They both focus on IP delivery of
content, either from ‘cloud to ground’ or from an in home gateway device. The competitive proposal is
an extension of technologies the MVPDs have already deployed and/or have presented to the FCC.
None of this requires any radical re-architecting of networks because it involves software protocols from
either the Cloud or in-home gateways, and not network hardware.
DSTAC WG4 Report
August 4, 2015
186
Network-sourced ad insertion is the norm for both traditional MVPDs and OVDs. YouTube for example
uses network-sourced ad insertion exclusively and not local insertion. Local insertion by the client is
extremely rare, primarily in limited one-way systems as noted in the DBS section. Ad insertion for VOD
(or any other content played back from an MVPD source directly, such as live linear TV, LookBack,
StartOver, cloud recorded DVR) is almost entirely network-sourced today. In the competitive proposal
MVPDs can implement novel interactive advertising models such as telescoping ads using an HTML 5
playback widget that would have full control over ad insertion and audience measurement. This does
not need to apply to recorded DVR content because for a retail DVR device built on this kind of system, if
the content is played back after being recorded, it is then under the user’s full control and should not be
subject to any service management by the MVPD. The competitive proposal supports delivery of content
over IP in the same manner of most OVD solutions, which means advertising (pre, post and interstitial) is
inserted in the network by manipulating the playlist of adaptive bitrate technologies such as HLS. This is
how the vast majority of content is delivered and multiple advertising models are supported today on
the Internet.
Both MVPD user interfaces and Competitive navigation devices based on CableCARD provide tools to
customers to block potentially objectionable content in a variety of ways by using the parental control
information delivered on the Cable plant and abstracted by the CableCARD. In the competitive proposal,
navigation devices can continue to innovate on such features in the user interface to give consumers
more choice in managing potentially offensive content. Users would not benefit from this innovation
under the MVPD-app only proposal.
The Competitive Proposal proposes the use of Public Key Infrastructure (PKI) certificates. As was noted
in the presentation to WG3 by NDS (Cisco), legacy conditional access systems used symmetric security
keys which made it very important that keys be kept secret and thus a non-trivial exercise to set-up and
share keys between vendors. PKI systems are based on asymmetric keys which are designed to allow
keys to be shared and even openly published without compromising security. PKI systems are also
pervasive in secure web services from electronic banking to secure email. Public source code exists and
is believed to increase security by allowing both hackers and defenders to continuous test the code
against threats. Using a PKI system over proprietary ones like in the MVPD UI proposal may be
significantly simpler for device manufactures to implement.
Practical System Design Concerns
To frame a comparison of these proposals, it is worth examining common architectural elements and
features of video distribution networks. In order to manage service entitlements, MVPD networks have
evolved from mere filtering and scrambling to cryptographic protection mechanisms leveraging
management facilities enabled by chains of cryptographic trust. Examination of system architectures
and design elements in furtherance of the DSTAC’s mission to “…promote the competitive availability of
navigation devices…” follows.
DSTAC WG4 Report
August 4, 2015
187
47 USC 629 (b) states “Protection of System Security: The Commission shall not prescribe regulations
under subsection (a) which would jeopardize security of multichannel video programming and other
services offered over multichannel video programming systems, or impede the legal rights of a provider
of such services to prevent theft of service.”
From this, the DSTAC can take assurance that any proposed system must fundamentally protect
multichannel video programming against theft of service and may not jeopardize security. Adherence to
best practices is fundamental to the design of secure systems. Listings of accepted industry-standard
guidelines can be found at owasp.org
82
, in Writing Secure Code by David LeBlanc and Michael Howard
83
,
or in Engineering Principles for Information Technology Security (A Baseline for Achieving Security),
Revision A
84
, published by the National Institute of Standards and Technology. For clarity, secure
engineering principles in this writing will reference NIST documentation.
Additionally, content distribution networks can be readily mapped to the Open Systems Interconnection
(OSI) model
85
(ISO/IEC 7498-1). The following analysis leverages this conceptual model for description of
underlying communications technologies, and readers unfamiliar with the OSI model are encouraged to
read either the standard or a summary (e.g. https://en.wikipedia.org/wiki/OSI_model).
In addition to consideration of fundamental secure system design principles, any system designed to
facilitate MVPD service integration per the DSTAC’s mission must remain “…uniform and technology-
and platform-neutral…” Due to this guidance, any system or protocol design calling for integration of
proprietary or service-specific technology is, necessarily, outside of the scope of the DSTAC. Such
service-specific technologies are typically coupled to OSI Layer 1 and/or Layer 2. For connectivity,
normalization at Layer 3-7 (e.g. IP, TCP, UDP, and above) provides the greatest potential for uniformity,
as even connector types, wire performance standards, and conductor count are not uniform among
various MVPD network technologies.
Though several key security principles are outlined by NIST in their guidelines, most critical in the design
of an interoperable and secure system are the following:
● Principle 2. Treat security as an integral part of the overall system design.
● Principle 3. Clearly delineate the physical and logical security boundaries governed by associated
security policies.
● Principle 6. Assume that external systems are insecure.
● Principle 9. Protect information while being processed, in transit, and in storage.
● Principle 12. Where possible, base security on open standards for portability and
interoperability.
● Principle 14. Design security to allow for regular adoption of new technology, including a secure
and logical technology upgrade process.
82
(https://www.owasp.org/index.php/Secure_Coding_Principles)
83
Writing Secure Code (2nd Edition) - David LeBlanc and Michael Howard ISBN-13: 978-0735617223 ISBN-10:
0735617228
84
Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A#,
written by Gary Stoneburner, Clark Hayden, and Alexis Feringa http://csrc.nist.gov/publications/nistpubs/800-
27A/SP800-27-RevA.pdf
85
ISO/IEC 7498-1, http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip
DSTAC WG4 Report
August 4, 2015
188
● Principle 24. Strive for simplicity.
● Principle 25. Minimize the system elements to be trusted.
Systems provided by third parties are fundamentally outside of the control of MVPDs, and, barring
significant advancements in cryptography beyond the current state of the art, no mechanism is available
to avoid adherence to Principle 6 (external systems are insecure) without coordination. Such secure
coordination can be assured via cryptographic signature chaining of executed functionality on specific
systems, further facilitated by roots of trust and secure protocols (e.g. Playready, Widevine, Fairplay). In
order to adhere to Principle 3 (clear delineation), Principle 24 (strive for simplicity), and Principle 25
(Minimize the system elements to be trusted), trusted code execution on devices under customer
control must be restricted to narrow components of device functionality. Ideally, such functionality is of
the minimal size as to be sufficient to implement necessary security protocols. This provides a
manageable minimal functional surface area, in order to reduce possible mechanisms of malicious
compromise. Engineers commonly refer to this principle as keeping a “small surface area” for attack,
denoting that large hardware/software interfaces are more difficult to secure against compromise.
Figure 42 - A canonical MVPD system encompassing a MVPD-provided tuner/DVR and a user-provided TV
DSTAC WG4 Report
August 4, 2015
189
In the case of a MVPD-provided set-top-box (STB) used with a MVPD distribution network, care must be
taken in the design of the system and STB to resist compromise by malicious modification of, or
intrusion into, the provided STB and/or the connection to the network. Such management is handled by
embedding critical functions into limited trusted secure elements of the system, further enabled by
cryptographic protection of the underlying content. Such a split between the “data plane” and “control
plane” of the system allows for rapid and unburdened development of the bulk of the hardware and
software of the system while maintaining robustness standards necessary to protect the underlying
content. Of note in Figure 42 is the fundamental directionality of media and input in the system.
Though secure-mode modules residing in the “data plane” may return narrow results and confirmation
to the “control plane”, the means of communication are necessarily narrow. Such a system design
provides for a limited attack surface area, enabling an elevated degree of trust.
The data plane vs. control plane separation is a semantic, physical, and functional separation in the
design of secure content systems. It is critical to understand that such a separation is fundamental to
the design and implementation of systems enabling content security.
Critically, the secure elements of these hardware platforms are designed to elevate the degree of
sophistication necessary to compromise the underlying content security. Debuggers, arbitrary code
execution, and software modification are all tools typically left available in untrusted execution
hardware, allowing for quick and effective software/hardware development. Control plane operations
are typically segregated to untrusted hardware or untrusted modes of execution on secure hardware.
Conversely, trusted execution environments, modes, and hardware disable these “software” or
“external” inspection mechanisms, forcing attackers to resort to more exotic means for intrusion (e.g.
hardware probing, chip shaving, electron microscopy). As such, critical content protection mechanisms
such as key storage, decryption, decode, and presentation are typically reserved for these functional
regions.
In Figure 43, all boxes outlined in purple are members of the data plane. In this case, it means that their
underlying hardware is either confirmably trusted (by means of cryptographic handshake, or, in literally
the case of some MVPD legacy CAS systems, armed guard) or content transiting this component is
encrypted. This allows for insecure hardware to participate in the facilitation of the secure data plane
through the use of a trusted decryption engine. Decryption modules for high-value data (e.g high
definition video content) are typically implemented in separate hardware or in protected hardware
operation modes (e.g. Trusted Execution Environment) that prohibit the unintended copying of
decrypted content, either through accident or abuse.
In essence, the data plane runs in secure software/hardware environments, and the control plane can
then run in insecure software/hardware environments. Furthermore, to protect the integrity and
security of the data plane, control plane functions must remain separated. These functions (e.g. User
interface, media transport control, network interface) are kept out of trusted environments, and
communication with, and operation of, data plane components is handled through small, manageable,
auditable functional interfaces. Security Principles 24 and 25 (Strive for simplicity and Minimize the
system elements to be trusted) address the necessity of this functional separation. Adherence to these
principles is critical to the design of effective content protection mechanisms.
Fortunately, this secure separation is exhibited in all of the proposed and sub-proposed systems, and it
is maintained by designing systems such that operations executed in insecure environments (e.g. a Hard
Disk Drive used to store programming, or an HDMI connector) are protected by cryptographic
authentication/keying protocol (e.g. Widevine, HDCP, DTCP/IP).
DSTAC WG4 Report
August 4, 2015
190
In the case of our proposals, systems broadly fall into two categories:
1. Link-protected local network systems
2. End-to-end systems
In the case of Device Specific Apps, content protection methodologies vary greatly, but methodologies
can fundamentally be broken into “software” and “hardware” systems, presumably to be covered by
WG3. Nonetheless, these systems generally fall into the End-to-end category of systems, as the content
is decrypted on the same physical device that will decode/deliver it, having previously been encrypted
once from operator. Device Specific Apps may, however, participate in a local system via Device Specific
Apps.
HTML5 Web Browser systems leveraging EME or other specific plugins for content protection also fall
into this End-to-end category, as, presumably, do Sling TV clients. In each of these cases, underlying
content remains in the same cryptographic domain until it is decrypted and decoded on a given device.
That device may then use cryptographic link protection (e.g. HDCP) to present still-protected content
that has never left the secure data plane. Such an approach could be used in a local system with
appropriate local key generation.
DLNA VidiPath and RVU represent architectures specifically designed to serve as Link-protected local
systems for redistribution of MVPD services. These systems both leverage DTCP/IP for local network
content protection, effectively abstracting content protection protocols down to local link protection.
The Competitive Navigation system proposal could serve as both an End-to-end system and a local
system. It specifically calls for a “Content Delivery Interface” that affords for a “Provider Interface”. A
provider interface effectively serves as a Virtual Headend device, allowing MVPDs to alter underlying
network delivery mechanisms without disturbing customer service. DLNA VidiPath devices, RVU devices
(such as DirecTV’s Genie), and the DISH Hopper are all examples, fundamentally, of Provider Interfaces.
DSTAC WG4 Report
August 4, 2015
191
Figure 43 - A "local", “gateway”, or "Provider Interface" example system encompassing a MVPD-provided interface, a third-
party/user-provided STB, and a user-provided TV
Note that certain elements, such as “Store Content” can be functionally relocated without adversely impacting content
security.
To afford for scalability requirements, video distribution systems do not generally provide content
streams cryptographically keyed to individually provisioned devices (as this would not scale at OSI Layer
1/Layer 2 effectively). Instead, content streams are uniformly encrypted using symmetric ciphers
leveraging keys propagated to trusted execution environments via challenge-response and
public/private key protocols. These challenge/response protocols call for bidirectional communication
not available end-to-end in broadcast and unidirectional systems (e.g. DBS). Such systems necessarily
resort to trusted (or partially trusted) Provider Interface devices able to securely manage extended
service functionality for non-integrated devices. Such functionality may include, but is not limited to,
entitlement management, purchase recording/reporting, and usage auditing. Current examples of such
systems include, but are not limited to, Dish Network’s Hopper, DirectTV’s Genie, and SiliconDust’s
HDHomeRun Prime, a third-party device interoperating via CableCARD with US domestic cable
networks.
Provider interfaces may also be used in bidirectional networks to terminate protocol or media variations
to interoperable interfaces. For example, ADSL modems serve as Provider Interfaces in AT&T UVerse
video distribution networks. In essence, a device that adapts a video distribution network to a different,
local distribution, network in the home may be thought of as a Provider Interface. Such canonicalization
is fundamental to affording for the evolution of MVPD networks while also stabilizing the means by
which third party devices may be integrated with MVPD services, and any mechanism affording for third
DSTAC WG4 Report
August 4, 2015
192
party device integration should, at the very least, facilitate the use of this category of device in provider-
to-user networks.
The Competitive Navigation system proposal addresses provider interfaces for local networks, necessary
to account for unidirectional network peculiarities and evolving MVPD technologies. The Operator
Provided User-Interface alternative system addresses this design constraint, though it is unclear in the
proposal which elements may be necessary to enable competitive navigation devices in possible
provider network configurations.
Figure 44 - An end-to-end network encompassing an MVPD system connected via a standardized transport to a third-party-
provided STB and a user-provided TV
MVPD networks are increasingly evolving to be end-to-end IP networks, possibly leveraging multicast
topologies for distribution efficiency. Such video distribution networks can leverage the same
underlying protocols used for Provider-Interface-based service distribution without incurring the added
costs of building, deploying, and maintaining Provider Interfaces.
Whether end-to-end IP systems involve OSI Layer 1 and Layer 2 functionality to the subscriber’s
premises, the [sic]
An appropriately established protocol or family of protocols can facilitate these and many other
modalities as various MVPD networks evolve in the face of wildly disparate underlying delivery
technologies. Properly designed and abstracted, such systems also allow for reliable competitive retail
navigation interface integration without encumbering MVPD service provider innovation. All of this can
further be done while maintaining content and service security by leveraging cryptographic roots of
trust, security-centric protocol design, and mindful segmentation of critical content-security functions
from other functional elements of MVPD networks and downstream distribution devices.
DSTAC WG4 Report
August 4, 2015
193
Similarities and Differences
Despite many differences in terminology, protocol selection, and problem set description, significant
similarities exist between these proposals.
Two critical conclusions should be drawn from this:
1. Both proposals indicate that it is clearly possible to implement sufficient content security
mechanisms to provide MVPD content services to third party devices.
2. By design, in both proposals (and sub-proposals of Part III: Section II.), content security
enforcement is independent of user-interface requirements. For any given capable security
mechanism provided, content security must fundamentally be orthogonal to the presentation of
user interface in order to capably maintain content security.
Both proposals address variations in MVPD network technologies and topologies, affording for
functional Provider Interface or local network distribution devices to be included where necessary.
Additionally, both proposals structurally lay out system designs incorporating secure elements that, with
varying degrees of modification, could include security systems proposed by WG3.
To provide an example of how one proposal may be adapted, let us start with a DLNA VidiPath example.
The VidiPath specification leverages HTML5 + EME + MSE to drive video playback via operator-controlled
user interfaces. In this scheme, only operators are able to provide navigation interfaces to customers,
leaving downstream devices to serve as undifferentiated dumb terminals. Though this is a significant
and material difference between these system proposals, a system such as DLNA VidiPath could be
adapted to provide catalog metadata relatively simply.
For example, a given VidiPath system could conceivably provide a lineup or manifest via XML, in its most
basic manifestation, such a presentation could look like:
<lineup provider="Comcast" zipcode="90210">
<channel>
<callsign>KTTVDT</callsign>
<network>FOX</network>
<number>4</number>
<package>Basic</package> <!-- for easier assocation with entitlement packages, alternatively the
provider could assign IDs to channels which associate with entitlements, or link entitlements directly to
callsign -->
</channel>
<channel>
<callsign>HBOHD</callsign>
<number>605</number>
<package>HBO</package>
<package>PremiumMovies</package>
</channel>
</lineup>
DSTAC WG4 Report
August 4, 2015
194
Such a system could be used, for example, to provide indexed access to a playback system using HTML5
+ EME + MSE with a canonicalized resource description mapping (e.g. predetermined http:// directory
structure). A more fully-functional example of a content catalog XML schema can be found in the SD&S
Schema in Annex C of ETSI TS 102 034 V1.5.1
86
. In essence the functional technical similarity between
Part III Section I and several sub-proposals (VidiPath, RVU, HTML5 + EME) of Part III Section II points to
the feasibility of a spectrum of capabilities that, if properly applied, could meet multiple important
goals:
1. Exposure of catalog and content metadata via protocols affords for the creation of competitive
navigation systems and innovative interfaces not yet conceived.
a. Such canonicalization also strongly facilitates essential accessibility capabilities (e.g. for
vision-impaired users) and limited-audience interface accommodations (e.g. for users
with severe physical, cognitive, mental, or sensory impairment).
b. Careful restriction of elements embodied in such a protocol could significantly reduce
the cost of implementation of competitive navigation devices, allowing for greater
adoption of cost-saving competitive navigation devices in low-income markets.
2. Optional affordance for MVPD-controlled remote user interfaces in such a system could provide
ample space for MVPDs to craft competitive and innovative user experiences independently of
navigation hardware. Such an accommodation coupled with protocol-based metadata and
management facilities could allow for MVPD-supplied innovation without leaving innovation
solely at the hands of MVPDs. Competitive navigation devices facilitating these optional features
could provide best-in-breed experiences driven by market responses to innovation and
competition.
86
ETSI TS 203 034 V1.5.1
http://www.etsi.org/deliver/etsi_ts/102000_102099/102034/01.05.01_60/ts_102034v010501p.pdf
DSTAC WG4 Report
August 4, 2015
195
References
[1] Louis D. Williamson, "FSN Technology," Proceedings: Society of Cable Television Engineers 1995
Conference on Emerging Technologies, Jan. 4-6, 1995, Orlando, FL, pp. 27-35.
[2] Michael B. Adams, "MPEG and ATM in the Full Service Network," Proceedings: Society of Cable
Television Engineers 1995 Conference on Emerging Technologies, Jan. 4-6, 1995, Orlando, FL, pp.
13-26.
[3] Ralph Brown and John Callahan, “Software Architecture for Broadband CATV Interactive Systems,”
NCTA Cable ’95 Proceedings, Dallas, TX, May 1995.
[4] PEGASUS PROGRAM, Request For Proposal and Functional Requirements Specification, V1.0, Time
Warner Cable - Engineering & Technology, March 6, 1996.
[5] ISO/IEC 13818-6:1998 - Information technology -- Generic coding of moving pictures and associated
audio information - Part 6: Extensions for DSM-CC.
[6] ISO/IEC 13818-2, 2000: Information technology—Generic coding of moving pictures and associated
audio (MPEG): Video.
[7] ATSC Digital Audio Compression Standard (AC-3, E-AC-3), Revision B.
[8] ISO/IEC 14496-10:2005: Information technology - Coding of audio-visual objects - Part 10:
Advanced Video Coding.
[9] ISO/IEC 13818-1, 2000: Information technology—Generic coding of moving pictures and associated
audio (MPEG): Systems.
[10] Federal Information Processing Standards Publication (FIPS PUB) 46-3, Data Encryption Standard.
[11] ANSI/SCTE 52 2008, Data Encryption Standard – Cipher Block Chaining Packet Encryption
Specification.
[12] ANSI/SCTE 65 2008, Service Information Delivered Out-Of-Band For Digital Cable Television.
[13] ANSI/SCTE 55-1 2002, Digital Broadband Delivery System: Out Of Band Transport Part 1: Mode A.
[14] ANSI/SCTE 55-2 2002, Digital Broadband Delivery System: Out Of Band Transport Part 2: Mode B.
[15] CableLabs Press Release, “Cable Industry Creates 'OpenCable™' Goal is Interoperable Set-top
Boxes”, September 4, 1997.
[16] OpenCable Host Device 2.1 Core Functional Requirements, OC-SP-HOST2.1-CFR-I15-120112,
January 12, 2012, Cable Television Laboratories, Inc.
[17] CEA-679-C Part B, National Renewable Security Standard (July 2005). A joint work of NCTA and
CEMA Technology and Standards.
[18] EN 50221-1997, EN 50221: "Common interface specification for conditional access and other digital
video broadcasting decoder applications".
[19] DOCSIS Set-top Gateway (DSG) Interface Specification, CM-SP-DSG-I20-120329, March 29, 2012,
Cable Television Laboratories, Inc.
[20] ANSI/SCTE 28 2007, HOST-POD Interface Standard
[21] OpenCable™ Software Request For Proposals, OC-RFP-990914, September 14, 1999, Cable
Television Laboratories, Inc.
[22] DVB Multimedia Home Platform 1.1.3, DVB-MHP 1.1.3, ETSI TS 102 812 V1.3.1 (2007-03), Blue book
A068r3.
[23] OpenCable Application Platform Specifications, OC-SP-OCAP1.2.2-120224, February 24, 2012, Cable
Television Laboratories, Inc.
[24] DVB Globally Executable MHP version 1.0.2, (GEM 1.0.2), ETSI TS 102 819 V1.3.1 (2005-10).
[25] Advanced Common Application Platform (ACAP), ATSC Document A/101A, February 12, 2009.
[26] Application Execution Engine Platform For Digital Broad Casting, ARIB STD-B23, Version 1.1,
Association of Radio Industries and Businesses, February 5, 2004.
DSTAC WG4 Report
August 4, 2015
196
[27] System Description, Blu-ray Disc Read-Only Format, Part 3-2: BD-J Specifications, version 2.4. Blu-
ray Disc Association, 2009.
[28] Host 2.0 DVR Extension, OC-SP-HOST2-DVREXT-I03-110512, May 12, 2011, Cable Television
Laboratories, Inc.
[29] OCAP Digital Video Recorder (DVR), OC-SP-OCAP-DVR-I08-120112, January 12, 2012, Cable
Television Laboratories, Inc.
[30] OpenCable Host Home Networking Extension 2.0, OC-SP-HOST-HN2.0-I06-120112, January 12,
2012, Cable Television Laboratories, Inc.
[31] Home Networking Protocol 2.0, OC-SP-HNP2.0-I07-120224, February 24, 2012, Cable Television
Laboratories, Inc.
[32] Reserved Services Domain Protocols Specification, OC-SP-RSD-PROT-I01-080828, August 28, 2008,
Cable Television Laboratories, Inc.
[33] Reserved Services Domain Technology Specification, OC-SP-RSD-TECH-I01-080630, June 30, 2008,
Cable Television Laboratories, Inc.
[34] OCAP Home Networking Extension, OC-SP-OCAP-HNEXT-I08-120112, January 12, 2012, Cable
Television Laboratories, Inc.
[35] Home Networking Security Specification, OC-SP-HN-SEC-I03-120112, January 12, 2012, Cable
Television Laboratories, Inc.
[36] Enhanced TV Application Messaging Protocol 1.0, OC-SP-ETV-AM1.0-I06-110128, January 28, 2011,
Cable Television Laboratories, Inc.
[37] Enhanced TV Binary Interchange Format 1.0, OC-SP-ETV-BIF1.0-I06-110128, January 28, 2011, Cable
Television Laboratories, Inc.
[38] HTTP Live Streaming, Internet Draft, http://tools.ietf.org/html/draft-pantos-http-live-streaming-16
[39] HTML5 - A vocabulary and associated APIs for HTML and XHTML, W3C Recommendation, World
Wide Web Consortium, http://www.w3.org/TR/html5/
[40] ISO/IEC 23009-1:2012: Information technology -- Dynamic adaptive streaming over HTTP (DASH) --
Part 1: Media presentation description and segment formats.
[41] ISO/IEC 23001-7:2012, Information technology -- MPEG systems technologies -- Part 7: Common
encryption in ISO base media file format files. International Standard. URL:
https://www.iso.org/obp/ui/#iso:std:iso-iec:23001:-7:ed-1:v1
[42] CAS / DRM Reality Check, Robin Wilson, Nagra, presented to DSTAC Working Group 2 (Technology
and Preferred Architectures), March 19, 2015.
[43] AT&T IPTV Technologies and Architectures, Ahmad Ansari, AT&T, presented to DSTAC Working
Group 2 (Technology and Preferred Architectures), March 12, 2015.
[44] Verizon Technologies and Architectures, Dan O’Callaghan, Verizon, presented to DSTAC Working
Group 2 (Technology and Preferred Architectures), March 12, 2015.
[45] Downloadable Security Technology Advisory Committee (DSTAC) Working Group 2 Report #1, April
21, 2015, https://transition.fcc.gov/dstac/wg2-report-01-04212015.docx.
[46] Cable Technologies And Architectures Overview, Ralph Brown, CableLabs, presented to DSTAC
Working Group 2 (Technology and Preferred Architectures), March 12, 2015.
[47] MPEG & IP Video Comparisons, Mark Vickers, Comcast, presented to DSTAC Working Group 2
(Technology and Preferred Architectures), March 12, 2015.
[48] DSTAC Presentation OMS and Optimum Services, Ken Silver, Cablevision, presented to DSTAC
Working Group 2 (Technology and Preferred Architectures), March 12, 2015.
[49] Charter DCAS Environment, Jim Alexander, Charter, presented to DSTAC Working Group 2
(Technology and Preferred Architectures), March 12, 2015.
DSTAC WG4 Report
August 4, 2015
197
[50] TWC IP Video Architecture, George Sarosi, Time Warner Cable, presented to DSTAC Working Group
2 (Technology and Preferred Architectures), March 12, 2015.
[51] Bright House Overview, Jeff Chen, Bright House, presented to DSTAC Working Group 2 (Technology
and Preferred Architectures), March 12, 2015.
[52] DBS Architecture Overview, John Card II, DISH & Steve Dulac, DirecTV, presented to DSTAC Working
Group 2 (Technology and Preferred Architectures), March 12, 2015.
[53] Cable Risk and Threats, Ralph Brown, CableLabs, presented to DSTAC Working Group 2 (Technology
and Preferred Architectures), March 19, 2015.
[54] MVPD CAS and DRM Trust Infrastructures, Ralph Brown, CableLabs, presented to DSTAC Working
Group 2 (Technology and Preferred Architectures), April 14, 2015.
[55] Open Source Implementations of CVP-2 Server and Client, CableLabs,
http://html5.cablelabs.com/dlna-cvp-2/index.html
[56] Reference Device Kit (RDK), http://rdkcentral.com
[57] W3C MSE, Media Source Extensions. http://www.w3.org/TR/media-source/
[58] W3C EME, Encrypted Media Extensions. http://www.w3.org/TR/encrypted-media/
[59] DLNA CVP-2 Press Release, March 18, 2014, http://www.dlna.org/docs/default-source/press-
releases/the-digital-living-network-alliance-releases-cvp-2-guidelines-for-viewing-subscription-tv-
content-on-multiple-home-devices.pdf?sfvrsn=4
[60] DLNA Guidelines, http://www.dlna.org/dlna-for-industry/technical-overview/guidelines
[61] W3C Crypto, Web Cryptography API. http://www.w3.org/TR/WebCryptoAPI/
[62] The Open SSL Project, https://www.openssl.org
[63] RemoteUIServer:1 Service Template Version 1.01, For UPnP™ Version 1.0, September, 2, 2004,
http://upnp.org/specs/rui/UPnP-rui-RemoteUIServer-v1-Service.pdf
[64] Mapping from MPEG-2 Transport to HTML5, I03, CL-SP-HTML5-MAP-I03-140207, Cable Television
Laboratories, Inc. Specifications, Web Technology, February, 7, 2014
[65] Server Sent Events, W3C Candidate Recommendation, 11 December 2012,
http://www.w3.org/TR/eventsource/
[66] DTCP Volume 1 Supplement E, Mapping DTCP to IP, Revision 1.4 ED3, June 5, 2013, Digital
Transmission License Administrator, http://www.dtcp.com/documents/dtcp/info-20130605-dtcp-
v1se-ip-rev-1-4-ed3.pdf
[67] UPnP Device Management: 2, http://upnp.org/specs/dm/dm2/
[68] IEEE 1905.1, IEEE Standard for a Convergent Digital Home Network for Heterogeneous
Technologies, 2013, http://standards.ieee.org/findstds/standard/1905.1-2013.html
[69] BasicManagement:2, Service Template Version 1.01, For UPnP™ Version 1.0, February 16
th
, 2012,
http://upnp.org/specs/dm/UPnP-dm-BasicManagement-v2-Service.pdf
[70] ConfigurationManagement:2, Service Template Version 1.01, For UPnP™ Version 1.0, March 4
th
,
2013,http://upnp.org/specs/dm/UPnP-dm-ConfigurationManagement-v2-Service.pdf
[71] EnergyManagement:1, Service Template Version 1.01, For UPnP™ Version 1.0, August 30, 2013,
http://upnp.org/specs/lp/UPnP-lp-EnergyManagement-v1-Service.pdf
[72] S. Santesson, TLS Handshake Message for Supplemental Data, IETF RFC 4680, September 2006,
http://tools.ietf.org/html/rfc4680
[73] T. Dierks, et al, The Transport Layer Security (TLS) Protocol, Version 1.2, IETF RFC 5246, August
2008, http://tools.ietf.org/html/rfc5246
[74] The WebKit Open Source Project, http://www.webkit.org
[75] Downloadable Security Technology Advisory Committee (DSTAC) Working Group 1 Report #1, April
21, 2015, https://transition.fcc.gov/dstac/wg1-report-01-04212015.pdf
DSTAC WG4 Report
August 4, 2015
198
[76] Report of WG1, MVPD Requirements and Content Providers Requirements {reference to document
goes here}
DSTAC WG4 Report
August 4, 2015
199
Tables in Document
Table 1 - Diversity of MVPD Customer Premise Equipment ......................................................................... 7
Table 2 - Comparison 802.11n and 802.11ac features ............................................................................... 30
Table 3 - Summary of MoCA 2.0 PHY and MAC Layer Parameters ............................................................. 34
Table 4 - MoCA 2.0 Power Mode Names and Description ......................................................................... 36
Table 5 - Sample OTT Service ca. Summer 2015 ......................................................................................... 43
Table 6 - Transport, Control, And Codec Support ....................................................................................... 47
Table 7 - Examples of Stream Management ............................................................................................... 50
Table 8- US Retail Device Numbers............................................................................................................. 73
Table 9 - MVPD Subscriber Count and Support for Personal Computers ................................................. 128
Figures in Document
Figure 1 - Typical Cable System Network Architecture ................................................................................. 9
Figure 2 - OpenCable/tru2way Interface Diagram ...................................................................................... 12
Figure 3 - DBS Architecture – Satellite to Home Distribution Path ............................................................. 14
Figure 4 - DIRECTV Uplink Facilities ............................................................................................................ 15
Figure 5 - DISH Uplink Facilities .................................................................................................................. 16
Figure 6 - DIRECTV Frequency Plan ............................................................................................................. 17
Figure 7 - DISH Frequency Plan ................................................................................................................... 18
Figure 8 - DIRECTV Server-Client Architecture............................................................................................ 20
Figure 9 - DISH Server-Client Architecture .................................................................................................. 21
Figure 10 - AT&T U-verse Architecture ....................................................................................................... 23
Figure 11 - ITU G.98x PON Optical Spectrum .............................................................................................. 24
Figure 12 - Verizon FiOS Access Network ................................................................................................... 25
Figure 13 - Verizon FiOS High-Level Architecture ....................................................................................... 26
Figure 14- Verizon FiOS Dual-Network Hybrid STB Architecture ................................................................ 26
Figure 15 - Example Home Network ........................................................................................................... 28
Figure 16 - Current in Home Wireless Technologies................................................................................... 28
Figure 17- MoCA 2.0 Extended Band D Frequency Plan ............................................................................. 34
Figure 18- Switched and Non Switched Video ............................................................................................ 50
Figure 19 - DLNA VidiPath Overview ........................................................................................................... 80
Figure 20 - DLNA VidiPath Architecture ...................................................................................................... 81
Figure 21 - VidiPath HTML5 RUI Usage Model............................................................................................ 82
Figure 22 - Secure content transmission using DTCP-IP ............................................................................. 84
Figure 23 - VidiPath Diagnostics Architecture ............................................................................................ 86
Figure 24 - DLNA Low Power Architecture ................................................................................................. 87
Figure 25 - HTTP-Adaptive Delivery Entities ............................................................................................... 88
Figure 26 - VidiPath Authentication Entities ............................................................................................... 89
Figure 27 - Hybrid In-home + Cloud Deployment ....................................................................................... 92
Figure 28 - In-home only Deployment ........................................................................................................ 93
DSTAC WG4 Report
August 4, 2015
200
Figure 29- Media Source Extensions Architecture ...................................................................................... 96
Figure 30- Encrypted Media Extensions Architecture ................................................................................ 97
Figure 31 - Detailed EME Architecture with APIs ........................................................................................ 98
Figure 32 - Creation of Passage Selective Multiple Encrypted Stream ..................................................... 102
Figure 33 – Typical Digital Cable System Architecture ............................................................................. 103
Figure 34 – Passage-enabled Digital Cable System .................................................................................. 104
Figure 35 – The Headend Encoding Process - 4 Steps - Selection, Duplication, Encryption and
Reconstruction .......................................................................................................................................... 105
Figure 36 – Passage Bandwidth Usage ..................................................................................................... 106
Figure 37 - Interfaces ................................................................................................................................ 115
Figure 38 - Overview of App Approach ..................................................................................................... 129
Figure 40 - Example App Interfaces ............................................................... Error! Bookmark not defined.
Figure 41 - HTML5/EME Implementation ................................................................................................. 137
Figure 42- Use of Passage to Enable End-to-End DRM ............................................................................. 175
Figure 43 - A canonical MVPD system encompassing a MVPD-provided tuner/DVR and a user-provided
TV .............................................................................................................................................................. 188
Figure 44 - A "local", “gateway”, or "Provider Interface" example system encompassing a MVPD-
provided interface, a third-party/user-provided STB, and a user-provided TV ........................................ 191
Figure 45 - An end-to-end network encompassing an MVPD system connected via a standardized
transport to a third-party-provided STB and a user-provided TV............................................................. 192
DSTAC WG4 Report
August 4, 2015
201
Part IV: Appendix A: Survey of Existing Devices
Description
Supports
Direct
Attach to
MVPD
Distribution
Network
Supports
Direct
Attach to IP
Network
Used for
Content
Distribution
Supports
Direct
Attach to
OTT
Network
Over
Internet
Supports
Local
Network
Connectivi
ty
Uses
Custom
Apps
Uses
HTML 5
Apps
Uses
Local
MVPD
Guide
Uses Remote
UI
Allows User
to Make
Local
Recordings
Provides
Access to
Cloud PVR
from
Competitive
Navigation
UI
Supports
Navigation
of MVPD
Linear
Service by
3rd Party UI
App
MVPD provided Set-top
Box
Yes
Some
87
Yes
YES
Yes
(Some)
YES
Yes, if
PVR
No
Yes
No
No
High Definition and 4K
Ultra HD TV – for IP and
other delivery paths
No
(assumes
Clear QAM
no longer
possible)
No
Yes,
smart TV
DLNA
Yes (OTT)
No
(Next Gen
Android
TV)
Yes
No for
MVPD,
creates
one for
over-the-
air
Broadcas
ts
No
No
N/A
No
RVU certified TV
Home
Network
No
Yes,
smart TV
DLNA
Yes, RVU
No
Remotely
Yes, with RVU
application
See
discussions
in Section
III system
proposals
N/A
with
DirecTV
SHEF
protocol
87
Not for DBS and QAM distribution.
DSTAC WG4 Report
August 4, 2015
202
Description
Supports
Direct
Attach to
MVPD
Distribution
Network
Supports
Direct
Attach to IP
Network
Used for
Content
Distribution
Supports
Direct
Attach to
OTT
Network
Over
Internet
Supports
Local
Network
Connectivi
ty
Uses
Custom
Apps
Uses
HTML 5
Apps
Uses
Local
MVPD
Guide
Uses Remote
UI
Allows User
to Make
Local
Recordings
Provides
Access to
Cloud PVR
from
Competitive
Navigation
UI
Supports
Navigation
of MVPD
Linear
Service by
3rd Party UI
App
VidiPath certified TV
Home
Network
Yes
Yes,
smart TV
DLNA
Yes,
VidiPath
(DLNA)
Yes,
VidiPath
for RUI,
VidiPath
2.0 will
have
cloud/
DRM
capability
Remotely
Yes, DLNA +
HTML 5
See
discussions
in Section
III System
proposals
No
No
MVPD Provided Home
Media Server (Content
Server on Home Network)
Yes
Yes
Yes
Yes
Yes
Yes
Yes, plus
additiona
l guide
data
provided
via
broadban
d
Yes, for
serving client
devices
Yes
Yes for
various
cable
systems, No
for current
satellite
delivered
services
Yes (custom
MVPD-
provided
custom API)
Home Video Gateway
from MVPD, Residential
Gateways (RG)
88
Yes
Yes
Yes
Yes
No
Yes
(Some)
Yes
Yes
(Some)
Yes
No
No
Digital Transport Adapter
(DTA)
Yes
No
Yes
Not
currently
Yes
Not
currently
No
No
Not
currently
No
No
88
AT&T DSL gateway includes wifi access.
DSTAC WG4 Report
August 4, 2015
203
Description
Supports
Direct
Attach to
MVPD
Distribution
Network
Supports
Direct
Attach to IP
Network
Used for
Content
Distribution
Supports
Direct
Attach to
OTT
Network
Over
Internet
Supports
Local
Network
Connectivi
ty
Uses
Custom
Apps
Uses
HTML 5
Apps
Uses
Local
MVPD
Guide
Uses Remote
UI
Allows User
to Make
Local
Recordings
Provides
Access to
Cloud PVR
from
Competitive
Navigation
UI
Supports
Navigation
of MVPD
Linear
Service by
3rd Party UI
App
Retail Whole Home DVR
Ecosystem (TiVo)
Yes
No
Yes
Yes
Yes
Yes
No
Yes, for VOD
and OTT
Yes
N/A
Yes
Media Player Box from
Retail (Roku, Apple TV,
Amazon, WD)
No
Yes
Yes
Yes
Yes
Yes
No
No
Some - This
is software
dependent
and highly
variable,
but coming
to more
current-run
devices via
software.
No, access
via MVPD
/OTT app
No, access
via MVPD
/OTT app
Media Player Sticks
(USB/HDMI)
No
Yes
Yes
Yes
Yes
Yes
No
No
Some - This
is software
dependent
and highly
variable,
but coming
to more
current-run
devices via
software.
No, access
via MVPD
/OTT app
No, access
via MVPD
/OTT app
Connected Tablet or
Smart Phone with Data
Plan or Wi-Fi
No
Yes
Yes
Yes
Yes
Yes
No
No
Software
dependent
(rare)
No, access
via MVPD
/OTT app
No, access
via MVPD
/OTT app
DSTAC WG4 Report
August 4, 2015
204
Description
Supports
Direct
Attach to
MVPD
Distribution
Network
Supports
Direct
Attach to IP
Network
Used for
Content
Distribution
Supports
Direct
Attach to
OTT
Network
Over
Internet
Supports
Local
Network
Connectivi
ty
Uses
Custom
Apps
Uses
HTML 5
Apps
Uses
Local
MVPD
Guide
Uses Remote
UI
Allows User
to Make
Local
Recordings
Provides
Access to
Cloud PVR
from
Competitive
Navigation
UI
Supports
Navigation
of MVPD
Linear
Service by
3rd Party UI
App
Broadband Connected
Blu-Ray Players
No
Yes
Some
Some
Some
Some
No
Yes
No
No, access
via MVPD
/OTT app
No, access
via MVPD
/OTT app
Notebook or Laptop
Computer (Apple,
Windows, Linux)
No
Yes
Yes
Yes
Yes, but
less
common
usage
Yes
No
No
Yes
No, access
via MVPD
/OTT app
No, access
via MVPD
/OTT app,
except
w/Windows
/OCUR
All-in-One or Desktop
Computer (Apple,
Windows, Linux)
No
Yes
Yes
Yes
Yes, but
less
common
usage
Yes
No
No
Yes
No, access
via MVPD
/OTT app
No, access
via MVPD
/OTT app,
except
w/Windows
/OCUR
Gaming Consoles (PS4,
Xbox)
No
Yes
Yes
Yes
Yes
Yes
No
No
Yes (Some)
No, access
via MVPD
/OTT app
No, access
via MVPD
/OTT app
Connected AV Receivers
Yes, radio
No, AV
Some
Some
Yes
Some
No
No
No
No
No
N/A
DSTAC WG4 Report
August 4, 2015
205
Description
Supports
Direct
Attach to
MVPD
Distribution
Network
Supports
Direct
Attach to IP
Network
Used for
Content
Distribution
Supports
Direct
Attach to
OTT
Network
Over
Internet
Supports
Local
Network
Connectivi
ty
Uses
Custom
Apps
Uses
HTML 5
Apps
Uses
Local
MVPD
Guide
Uses Remote
UI
Allows User
to Make
Local
Recordings
Provides
Access to
Cloud PVR
from
Competitive
Navigation
UI
Supports
Navigation
of MVPD
Linear
Service by
3rd Party UI
App
Internal/External Tuners
(Hauppauge, Silicon Dust,
Sat-IP)
Yes
No
No
Via 3rd
party
service
89
Via 3rd
party
service
89
Via 3rd
party
service
89
Not from
MVPD
Guide,
sourced
externally
via 3
rd
party
service
Via 3rd party
service
89
Via 3rd
party
service
89
No
Via 3rd
party
service
89
External/External Tuners
(Hauppauge, Silicon Dust,
Sat-IP)
Yes
No
No
Yes; DLNA,
DTCP-IP,
OCUR/DRI,
or custom
protocols
3
rd
party
client apps
supported
Via 3rd
party
client
Not from
MVPD
Guide,
sourced
externally
via 3
rd
party
service
Via 3rd party
client
implementati
on
Via 3rd
party client
No
Via 3rd
party client
using DLNA
or
OCUR/DRI
89
3rd party services for internal/external tuners can be protocol based servers or direct clients such as:
- VLC media player client
- DLNA Digital Media Servers, such as tv-now
- Windows Media Center
- Windows Media Player
- Command line tools
- Custom applications (Hauppauge WinTV, etc)
DSTAC WG4 Report
August 4, 2015
206
Description
Supports 3rd
Party Apps
Supports
3rd Party
Access from
external
device
Works across MVPD
Network Technologies
(Cable, IPTV, Satellite)
Portable across
MVPDs (within
Cable or within
Satellite)
Supports
ATSC Tuner
and Guide
Integration
Supports
National
EAS
Universal
Remote
Control
Support
Supports
Multiple Tuner
Management
and Conflict
Resolution
Supports
archiving
customer-
recorded
content to
external storage
MVPD provided Set-top Box
(Some) YES
(Some) YES
No, MVPD Network
Technology specific
(Some) YES
(Some)
YES
Yes
Yes
Yes, in whole
home DVR
Some
90
High Definition and 4K Ultra
HD TV – for IP and other
delivery paths
Yes, smart TV
Yes, smart
TV based on
Android
HDMI, VidiPath, RVU
HDMI, VidiPath,
RVU
Yes, a
guide can
be
generated
by scanning
channels
and using
event
informatio
n tables
Yes
Yes
Usually a single
tuner now, PiP
feature is gone
Japanese,
European
Models
RVU certified TV
Yes
TBD
if RVU used
if RVU
Not RVU
Feature
Yes
Yes
Same
Not RVU
Feature
VidiPath certified TV
Yes
TBD
if VidiPath used
if VidiPath
Not
VidiPath
feature
Yes
Yes
Same
Not VidiPath
feature
90
Some DISH STBs support use of customer-provided USB HDD for external archive (not export) and DVR functions.
DSTAC WG4 Report
August 4, 2015
207
Description
Supports 3rd
Party Apps
Supports
3rd Party
Access from
external
device
Works across MVPD
Network Technologies
(Cable, IPTV, Satellite)
Portable across
MVPDs (within
Cable or within
Satellite)
Supports
ATSC Tuner
and Guide
Integration
Supports
National
EAS
Universal
Remote
Control
Support
Supports
Multiple Tuner
Management
and Conflict
Resolution
Supports
archiving
customer-
recorded
content to
external storage
Home Media Server (Content
Server on Home Network)
Yes (MVPD-
provided
custom API)
Some
No, except for certain
OTT-provided services
No
Yes
Yes
Yes
Yes
Yes
Home Video Gateway from
MVPD, Residential Gateways
(RG)
88
No
No
No
No
No
Some
No
No
No
Digital Transport Adapter
(DTA)
No
No
No, cable specific
technology
Yes
No
Yes
Yes
No
No
Retail Whole Home DVR
Ecosystem (Tivo)
Yes
Yes
No
All Cable
Yes
Yes
Yes
Yes
Yes
Media Player Box from Retail
(Roku, Apple TV, Amazon,
WD)
Yes
Yes
HDMI, local or
network gateway
HDMI, local or
network
gateway
With ATSC
gateway
Software
(and
gateway)
depende
nt.
Yes. BT,
WiFi, and
IR support
varies by
device.
Tuner,
gateway,
software
specific.
Variable
(software and
hardware
specific)
Media Player Sticks
(USB/HDMI)
Yes
Yes
HDMI, local or
network gateway
HDMI, local or
network
gateway
With ATSC
gateway
Software
(and
gateway)
depende
nt.
Yes. BT,
WiFi, and
IR support
varies by
device.
Tuner,
gateway,
software
specific.
Variable
(generally not
local storage,
but network
storage)
DSTAC WG4 Report
August 4, 2015
208
Description
Supports 3rd
Party Apps
Supports
3rd Party
Access from
external
device
Works across MVPD
Network Technologies
(Cable, IPTV, Satellite)
Portable across
MVPDs (within
Cable or within
Satellite)
Supports
ATSC Tuner
and Guide
Integration
Supports
National
EAS
Universal
Remote
Control
Support
Supports
Multiple Tuner
Management
and Conflict
Resolution
Supports
archiving
customer-
recorded
content to
external storage
Connected Tablet or Smart
Phone with Data Plan or Wi-Fi
Yes
Yes
HDMI, local or
network gateway
HDMI, local or
network
gateway
With ATSC
gateway
Software
(and
gateway)
depende
nt.
91
Yes. BT,
WiFi, and
IR support
varies by
device.
Tuner,
gateway,
software
specific.
Variable (local
MMC/SD or
network
storage)
Broadband Connected Blu-Ray
Players
Yes
Yes
HDMI, local or
network gateway
HDMI, local or
network
gateway
With ATSC
gateway
Software
(and
gateway)
depende
nt.
Yes. BT,
WiFi, and
IR support
varies by
device.
Tuner,
gateway,
software
specific.
With
computer/gate
way assistance
(e.g. Plex, Kodi)
Notebook or Laptop Computer
(Apple, Windows, Linux)
Yes
Yes
HDMI, local or
network gateway
HDMI, local or
network
gateway
With ATSC
gateway or
built-
in/optional
tuner
(PCIe, USB,
etc)
Software
(and
gateway)
depende
nt.
Yes. BT,
WiFi, and
IR support
varies by
device.
Tuner,
gateway,
software
specific.
Yes
All-in-One or Desktop
Computer (Apple, Windows,
Linux)
Yes
Yes
HDMI, local or
network gateway
HDMI, local or
network
gateway
With ATSC
gateway or
built-
in/optional
tuner
(PCIe, USB,
etc)
Software
(and
gateway)
depende
nt.
Yes. BT,
WiFi, and
IR support
varies by
device.
Tuner,
gateway,
software
specific.
Yes
91
Tablets with Data Plan may also support WEA; Connected Smartphone with Data Plan is generally required to support WEA; Connected Smart Phone with
Wi-Fi may support WEA.
DSTAC WG4 Report
August 4, 2015
209
Description
Supports 3rd
Party Apps
Supports
3rd Party
Access from
external
device
Works across MVPD
Network Technologies
(Cable, IPTV, Satellite)
Portable across
MVPDs (within
Cable or within
Satellite)
Supports
ATSC Tuner
and Guide
Integration
Supports
National
EAS
Universal
Remote
Control
Support
Supports
Multiple Tuner
Management
and Conflict
Resolution
Supports
archiving
customer-
recorded
content to
external storage
Gaming Consoles (PS4, Xbox)
Yes
Yes
HDMI, local or
network gateway, or
HDMI passthrough
HDMI, local or
network
gateway
With ATSC
gateway or
USB tuner
Software
(and
gateway)
depende
nt.
Yes. BT,
WiFi, and
IR support
varies by
device.
Tuner,
gateway,
software
specific.
Yes
Connected AV Receivers
N/A
N/A
HDMI
HDMI
N/A
N/A
N/A
N/A
N/A
Internal Tuners (Hauppauge,
Silicon Dust, Sat-IP)
requires 3
rd
party app
89
requires 3rd
party app
89
Some tuners support
more than one
DBS/terrestrial/Cable
standard
Yes
N/A
N/A
N/A
N/A
N/A
External Tuners (Hauppauge,
Silicon Dust, Sat-IP)
requires a
client
89
requires 3rd
party app or
OCCUR
client
89
Some tuners support
more than one
DBS/terrestrial/Cable
standard???
OCUR on Cable
N/A
N/A
N/A
N/A
N/A
