ETSI TR 102 688-2 V1.1.1 (2010-03)

ETSI TR 102 688-2 V1.1.1 (2010-03)
Technical Report


Media Content Distribution (MCD);
MCD framework;
Part 2: Views and needs of content providers

---------------------- Page: 1 ----------------------
2 ETSI TR 102 688-2 V1.1.1 (2010-03)



Reference
DTR/MCD-00002
Keywords
audio, broadcast, content, IP,
multimedia, TV, video
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2010.
All rights reserved.

TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TR 102 688-2 V1.1.1 (2010-03)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Methodology . 9
5 Ecosystem . 9
5.1 The "content provider" cloud . 9
5.2 Relationships with other actors . 10
6 Non-technical constraints . 11
6.1 Business model choices . 11
6.2 Contractual constraints . 11
6.3 Convergent models . 12
6.4 Advertising constraints . 12
7 Interfaces positions and roles . 13
7.1 Block diagram . 13
7.2 Content flow . 13
7.3 Content portal . 14
7.4 Reporting flow . 14
8 Interface formats and protocols . 15
8.1 Interface with the user equipment . 15
8.2 Interaction with the user . 16
8.3 Feeding the CDN with media files . 16
8.4 Feeding the CDN with meta-data . 17
8.5 Feeding the CDN with streams . 17
8.6 Reporting from the CDN . 18
9 Conclusions . 18
Annex A: Content providers' questionnaire . 20
A.1 Introduction and Scope . 20
A.2 Questions . 20
A.2.1 Ecosystem and Business Models . 20
A.2.2 Advertising . 21
A.2.3 General Content Delivery . 21
A.2.4 CDN . 22
A.2.5 Network QoS . 22
A.2.6 Audience Measurement . 23
A.2.7 Applications Convergence. 23
History . 24

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 102 688-2 V1.1.1 (2010-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Media Content Distribution (MCD).
This is a multi-part deliverable identifiable by the same main number and a common part of the title. This set of partial
deliverables (parts and sub-parts handled and published independently but treated in a coordinated form) build a whole
deliverable handling the subject identified by the common part of the title.
The common part of the title is Media Content Distribution framework.
Each part and sub-part of the present set of deliverables covers a specific subject specified in the corresponding scope
and referred to in the specific part of the title. To each part and sub-part of the whole deliverable a specific number
attached to the common main number of the deliverable will also be assigned.
The present document, the only one providing a collection of the concerns and needs expressed by Content Providers,
is part 2 of the multi-part deliverable covering the Media Content Distribution framework, as identified in part 1 of
this multi-part deliverable.
For a rational maintenance and easy usage of the complete set of the documents, only part 1 of the set of the documents,
will maintain an updated list of the documents in the series, all the other documents should refer to part 1, working
therefore as the central point of the series.
Introduction
In the context of MCD work, as explained in part 1 of this multi-part deliverable, the collection of Content Providers
views and needs were early identified as a major step to proceed to the necessary analysis in this sector.
Content Providers have clear ideas on the consumers's needs, they understand the environment of MCD and start to take
advantage of the different MCD means offered by the convergence of technologies and systems. Their opinion is
therefore a central tool for the identification of MCD requirements and the specification of a roadmap for the
standardization work to be developed.
In addition commercial solutions developed by different market players do not interoperate across platforms. The crux
of the matter is that at one end, content providers face the challenge to provide different content formats to the various
distribution pipes, which in turn generates unbearable costs, whilst at the other end, customers' buy-in remains well
below expectations.
If some particular standards are centred in the Contents Providers needs and views, reference should be made to them.
E.g. some discussions on H4TV, a standard for the authoring and interoperable delivery over broadcast and on line
media of interactive services authored in a web technologies-based format, should be included since this standard is
very much Content Providers' needs oriented.
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 102 688-2 V1.1.1 (2010-03)
Most important requests for MCD platforms and systems, like interoperability, Quality of Service (QoS) and Quality of
Experience (QoE), Security and content owner rights, and many others are reflected in the structure of the present
document in order to facilitate its usage and to help further discussions for the establishment of MCD requirements and
roadmap. The conclusions achieved for each one of the areas of the identified needs may result later in new parts of this
multi-part deliverable, where each one of the most relevant subjects will be handled in depth, beneficiating from
conclusions obtained in other parts of this multi-part deliverable.
The work TC-MCD is undertaking intends to be based on a 'neutral, objective, independent approach' in order to
prevent cooperation difficulties with relevant players and, most of all, to ensure that no biaising effect is introduced in
the market own choices. No preference should be demonstrated for any solution or system on the market, but the
objective advantages of some systems when satisfying some particular requirements should be noted.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 102 688-2 V1.1.1 (2010-03)
1 Scope
The present document belongs to a set of deliverables proceeding to the widest possible coordinated study on the media
content distribution (MCD) matters with the primarily goal of identifying standardization needs not covered or not
correctly covered at the present stage of development. This set of documents will cover at least the activities and areas
better specified in part 1 of this set of documents.
The present document is part 2 of the set of documents and collects, lists and discusses the Content Providers needs and
opinions falling within the wide scope of this set of documents.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] IETF RFC 959: "File Transfer Protocol".
[i.2] Secure File Transfer Protocol, Internet-Draft, Secsh working group of the IETF.
[i.3] IETF RFC 2616: "HyperText Transfer Protocol".
[i.4] IETF RFC 2818: "HyperText Transfer Protocol Secure".
[i.5] W3C, eXtensible Markup Language, XML 1.0.
[i.6] SMPTE 0377: "Material Exchange Format (MXF) - File Format Specification".
NOTE: For SMPTE documents see http://store.smpte.org/category-s/1.htm and use the Search engine.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 102 688-2 V1.1.1 (2010-03)
[i.7] EBU Tech 3264: "Subtitling data exchange format" (EBU-STL).
NOTE: See http://tech.ebu.ch/webdav/site/tech/shared/tech/tech3264.pdf.
[i.8] ETSI TS 102 796: "Hybrid Broadcast Broadband TV".
[i.9] SMPTE 0259M : "Television - SDTI Digital Signal/Data - Serial Digital Interface".
[i.10] SMPTE 292: "1.5 Gb/s Signal/Data Serial Interface".
[i.11] Open Mobile Alliance, OMA DRM 1.0.
[i.12] OpenCable, OCAP 2.0.
[i.13] Electronic Industries Alliance, EIA-608/CEA-708.
[i.14] W3C, Distribution Format Exchange Profile.
[i.15] SMPTE Metadata Dictionary: SMPTE RP 0210 ("Metadata Dictionary Registry of Metadata
Element Descriptions") and SMPTE RP 0224 ("SMPTE Labels Register").
[i.16] ITU-T Recommendation Q.6/SG16, H263.
[i.17] ISO/IEC 14496-2: "MPEG-4".
[i.18] ISO/IEC 14496-10: "MPEG-4 AVC".
[i.19] ETSI TS 102 825: "Digital Video Broadcasting (DVB); Content Protection and Copy Management
(DVB-CPCM)".
[i.20] Marlin, Marlin Developer Community.
[i.21] SMPTE 0421M : "Standard for Television - VC-1 Compressed Video Bitstream Format and
Decoding Process".
[i.22] ISO/IEC 13818-2: "MPEG-2".
[i.23] ATSC A/52B.
[i.24] ISO/IEC 11172-3: "MPEG-1 layer II".
[i.25] ISO/IEC 13818-7: "Advanced Audio Coding".
[i.26] ETSI EN 300 472: "Digital Video Broadcasting (DVB); Specification for conveying ITU-R
System B Teletext in DVB bitstreams".
[i.27] ETSI EN 300 743: "Digital Video Broadcasting (DVB); Subtitling systems".
[i.28] Adobe, Real-Time Messaging Protocol.
[i.29] IETF RFC 3550: "Real-time Transport Protocol".
[i.30] IETF RFC 2326: "Real-Time Streaming Protocol".
[i.31] IETF RFC 768: "User Datagram Protocol".
[i.32] ISO/IEC 13818-1: "MPEG-2 Transport Stream".
[i.33] W3C, Scalable Vector Graphics.
[i.34] ISO/IEC 13522-5: "Multimedia and Hypermedia Experts Group, MHEG-5".
[i.35] ETSI TS 102 590: "Multimedia Home Platform".
[i.36] Cineform.
NOTE: See http://www.cineform.com/technology.php.
[i.37] Microsoft, Microsoft Media Server.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 102 688-2 V1.1.1 (2010-03)
[i.38] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI)
in DVB systems".
[i.39] ISO/IEC14496-3: "Advanced Audio Coding".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
adaptive streaming: process that adjusts the quality of a video based on changing network conditions to ensure the best
possible viewer experience
advertising agency: service business dedicated to creating, planning and handling advertising
catchup TV: video on demand service delivering content for a short period after its broadcasting on a television
channel
content: information and experiences that may provide value for a viewer
content delivery network: system of computers containing copies of a content, placed at various nodes of the Internet
so as to shorten the path and lower the network congestion between the server and the client
content provider: any actor distributing content through a content delivery network
digital rights management: access control technology imposing limitations on the usage of digital content
mezzanine file: high-quality file acting as the reference file from which lower-quality copies are derived
operator: organization that provides network services through wired or wireless connections
peer to peer: distributed system of end-user computers providing content delivery services
progressive download: method for transmitting non-live video to the user for immediate playback, using buffers to
avoid network congestion
streaming: process of transmitting content in real-time over the Internet without local buffering
trick play: functionality allowing to pause, change the speed of playing and seek in a given content
watermarking: process of embedding unperceivable information in a video or audio signal, for instance in order to
identify the source of the content
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Program Interface
CDN Content Delivery Network
CP Content Provider
DRM Digital Rights Management
DTD Document Type Definition (XML)
DTT Digital Terrestrial TV
EITp/f Event Information Table, present and following (DVB)
EPG Electronic Programme Guide
HD High Definition
IP Internet Protocol
IPTV Internet Protocol TeleVision

NOTE: Based on ITU definition and TISPAN work.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 102 688-2 V1.1.1 (2010-03)
MCD Media Content Distribution
MMS Microsoft Media Services
QoS Quality of Service
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SDO Standards Development Organization
STB Set-Top Box
TDF Télédiffusion de France (company)
TMP Télévision Mobile Personnelle (DVB-H project in France)
TS MPEG-2 Transport Stream
VOD Video On Demand
4 Methodology
Content providers are traditionally under-represented in standard organizations. Nevertheless they regularly submit
presentations and templates to the governments, regulators, or local industry forums. At first we have gathered a
number of them, and tried to draw common lines of actions. This has proved an uneasy task. Furthermore, it also hides a
lot of smaller issues, which content providers do not necessarily think of bringing to the public attention.
We have therefore decided to take a proactive approach, and organize series of interviews with selected content
providers. We have thought important that:
• Though a questionnaire has been developed in the MCD group, the questions were not closed. The
questionnaire was designed to make sure no topic was forgotten during the discussion, but the interviewees
had full liberty to talk about what comes to mind first.
• The interviews had to be done one at a time, to make sure that a CP would not influence the others. It has put
into focus a lot of drifts or full disagreements between interviewees, but it has also taken an awful lot of time,
which explains the limited number of interviews.
• The choice of interviewees should include personalities well known among CP for their insight, but
representing very different types of content providers. For instance:
- Large public broadcaster;
- Large commercial broadcaster;
- Small commercial broadcaster;
- Large VOD provider;
- Small VOD provider;
- And lots of hybrid models.
The present document is the abstract of the series of interviews we have done. For confidentiality reasons, the names of
the interviewees and companies have been removed.
5 Ecosystem
5.1 The "content provider" cloud
When first trying to define with the CP the ecosystem they imagine, we have stumbled across major divergences
between the interviewees. These can be traced back to the fact that the "content provider" term is much harder to define
than we imagined, and may regroup - or not - different roles such as:
• broadcast channels;
• aggregators (live or on-demand);
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 102 688-2 V1.1.1 (2010-03)
• distributors;
• content producers;
• advertising agencies.
All the broadcast channels we have talked to view themselves as "aggregators"; for some of their contents, they can also
be distributors or content producers. Also they can have an internal advertising agency, competing with the agencies of
the Internet or of telecom operators.
VOD portals are also, in a more obvious way, "aggregators". At some point there can be several levels of aggregation.
Many companies have a hybrid business model.
We have long considered whether and how to include those roles in an analytical view of the CP ecosystem. In the end,
one question prevailed: if we chose to make those roles appear, would TC-MCD have anything to do in these areas?
From the discussions with the interviewees, it appeared very clear that the interfaces between those "roles" or actors (in
case they are born by different companies) had a strong link with the contractual side of the relationship; implying that
how the content is distributed is very much dictated by the terms of the contracts that bound the actors, or internal
processes (for that matter, juxtaposing several roles in the same company does not seem to simplify the processes). Also
in most cases the number of actors is fairly small. Practically content providers do not automatize any task in that area,
and though it would sometimes be needed, they fail to see how it could be feasible.
As a conclusion, we have decided to promote a very simple definition of the term "Content Provider":
content provider: any actor distributing content through a content delivery network.
5.2 Relationships with other actors
We have proposed the following schematic to interviewees, as a basis for discussion.

Figure 5.1: The Content Provider Ecosystem
Some interviewees would like to add the traditional broadcast operators in the schematic, in a symmetrical position with
the network operators. We believe that the interfaces and roles between CPs and broadcast operators are already
well-defined elsewhere and out of the scope of TC-MCD.
Some want to draw a link between the users and the content providers. They argue that CPs are represented as a brand
to the users, and take responsibility for the selection and presentation of contents. As such, they get user feedback and
recognition. However these are not technical relationships and are out of the scope of TC-MCD.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 102 688-2 V1.1.1 (2010-03)
For some CPs, the "Internet CDN" is seen as a technical subcontractor of the content provider, and should not be placed
on the same level as the network operators. It belongs then to the "content provider cloud". It can also be noted that
some CPs have a very aggressive strategy towards IPTV, and tend to create their own internal Internet CDN. That's one
of the reasons why several interviewees have asked for a direct connection between the Content Provider and the User.
Finally, most interviewees put a lot of emphasis on audience measurement. They distinguish two different ways of
measuring audience:
• qualified audience: it is very important for advertisers;
• raw numbers of viewers: they can be consolidated to repay royalties to content owners or societies of authors.
CPs stress the fact that network operators do not release their figures: it would indirectly give information to their
competitors about their user base. In some cases (TMP, or mobile TV in France) operators are forced by contract to
communicate the audience of the channels. Some interviewees call for the development of an "audience mediator" role
between the operators and the CP, which would consolidate the figures of the operators while enforcing privacy and
confidentiality constraints.
6 Non-technical constraints
6.1 Business model choices
There can be a lot of differences in the technical architecture and constraints, depending on the choice of business
model of the company. First come to mind the live vs. on-demand services. Most VOD services use progressive
download, so that they can work around the lack of QoS and poor network conditions. Some are looking at streaming,
or adaptive streaming.
VOD interfaces are well-defined (based on media file + meta-data exchanges) and widely used. Stream interfaces are
mostly ad-hoc solutions; in some cases the captation of the stream is completely subcontracted to a CDN, often by
traditional broadcast means (DTT or satellite).
Another important choice is the number of subcontractors the CP has. Some choose to have only one CDN distributing
the content to the Internet; others multiply the supported platforms and the operators (e.g. IPTV STB networks). In the
latter case, CPs are exhausted by the lack of standardised interfaces and have to redevelop everything for each platform.
Billing interfaces can also be impacted: the CP can choose to charge the client directly with credit card, charged calls or
text messages. Or it relies on the telecom operators in-between and their internal billing system, with which they have to
communicate.
6.2 Contractual constraints
A few common points stand out from the contracts of the content owners:
• contents are bought for a defined territory; geolocking needs to be enforced;
• contents have a window of availability;
• CP needs to have the ability to remove very quickly a content.
Also in some cases, the contract defines the platforms (network operators) and ways of reception (STB/TV, PC,
mobile, etc.). If a platform or a way is to be added, the contract needs to be renegotiated, and it costs money.
Except in the case of a broadcaster publishing its own internally-produced contents, the contracts also require content
protection measures to be enforced. The sim
...