ETSI TR 102 688-9 V1.1.1 (2013-07)

Technical Report
Media Content Distribution (MCD);
MCD framework;
Part 9: Content Delivery Infrastructures (CDI)

2 ETSI TR 102 688-9 V1.1.1 (2013-07)

Reference
DTR/MCD-00008
Keywords
BROADCAST, content, multimedia, 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 2013.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are Trade Marks of ETSI 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
3 ETSI TR 102 688-9 V1.1.1 (2013-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
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 . 9
4 Role of Content Delivery Infrastructures . 10
5 Use cases and Requirements . 10
5.1 Requirements from Content Providers . 10
5.2 Specific Use Cases . 11
5.3 Specific Requirements . 11
6 Taxonomy of CDNs . 12
6.1 Traditional Internet CDN . 12
6.2 Operator VOD CDNs . 13
6.3 Caches . 13
7 State of the art . 13
7.1 Existing and upcoming CDN Architecture Standards . 13
7.1.1 ITU-T IPTV GSI, SG13 and SG16 . 13
7.1.1.1 Assessment . 15
7.1.2 ETSI TISPAN . 16
7.1.2.1 Assessment . 18
7.1.3 ATIS IIF . 18
7.1.3.1 Assessment . 19
7.1.4 Open IPTV Forum . 20
7.1.4.1 Assessment . 20
7.1.5 DVB . 20
7.1.5.1 Assessment . 21
7.1.6 3GPP . 21
7.1.6.1 Assessment . 21
7.1.7 IETF CDNi . 22
7.1.7.1 Assessment . 23
7.1.8 OMA . 23
7.2 Existing and upcoming Content Delivery Protocols . 24
7.2.1 HTTP . 24
7.2.2 OIPF Adaptive Streaming . 24
7.2.3 3GPP HTTP Adaptive Streaming . 24
7.2.4 MPEG DASH . 24
7.2.5 ATIS Adaptive Streaming . 25
7.2.6 DVB Adaptive Streaming . 25
7.2.7 DTG Adaptive Streaming . 25
7.2.8 IETF HTTP Live Streaming . 25
7.2.9 IETF and Content Delivery . 25
7.3 Existing and upcoming Content Injection related protocols . 25
7.3.1 CableLabs Asset Distribution Interface (ADI) . 26
7.3.2 ISO Archival Interfaces . 26
7.4 Existing CDN Proprietary Solutions . 26
8 Gap Analysis . 26
ETSI
4 ETSI TR 102 688-9 V1.1.1 (2013-07)
9 CDN Architectures and Interfaces. 27
9.1 Content Delivery . 28
9.2 Content Control (Cc) . 28
9.3 Content Provision (Cp) . 28
9.4 CDN Interconnection (Ci) . 29
10 Conclusions and Recommendations . 29
Annex A: Bibliography . 31
History . 32

ETSI
5 ETSI TR 102 688-9 V1.1.1 (2013-07)
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://ipr.etsi.org).
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, detailing the necessary components
and interfaces.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Media Content Distribution (MCD).
The present document is part 9 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.1].
The present document is part of a series of Technical Reports that are providing a landscape of the subjects pertaining to
Media and Content Distribution. The present document reviews Content Delivery Infrastructures.
Introduction
The last decade has seen a flurry of standards compete for attention in the space of IPTV and mobileTV, in addition to
an already large number of proprietary systems. This has resulted in confusion and a lack of agreed standards, leading to
the domination of proprietary implementations. Because these implementations could work in isolation without adverse
relationships with the IP networks, the damage was limited to the creation of non interoperable islands, with operators
building their proprietary universe in a piecemeal fashion with very limited possible reuse, increasing costs.
The next steps are seeing how TV and video applications now connect to the internet at large. The internet is a different
setting: it is shared by everyone and based on strongly established legacy standards, but it is also facing the challenge of
delivery content on a scale that may be above its capabilities. The growth of the Web has been made possible by the
internet commercial Content Delivery Networks, which has allowed large-scale delivery of Web content.
The role of the present document is to set the stage for creating Technical Specifications in the domain of Content
Delivery Infrastructures standards.
ETSI
6 ETSI TR 102 688-9 V1.1.1 (2013-07)
1 Scope
The present document is part 9 of the set of documents described in TR 102 688-1 [i.1].
The present document describes the domain of Content Delivery Infrastructures and the existing solution elements. It
also identifies the Use Cases and Requirements that should be satisfied by the resulting solution, perform a Gap
Analysis of the state of the art with respect to the requirements and outlines elements of solution that could result in new
specifications.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
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 necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 102 688-1: "Media Content Distribution (MCD); MCD framework; Part 1: Overview of
interest areas".
[i.2] ETSI TR 102 688-2: "Media Content Distribution (MCD); MCD framework; Part 2: Views and
needs of content providers".
[i.3] ETSI TS 182 019: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Content Delivery Network (CDN) Architecture".
[i.4] IETF RFC 3466: "A Model for Content Internetworking (CDI)".
[i.5] ETSI TS 102 990: "Media Content Distribution (MCD); CDN Interconnection, use cases and
requirements".
[i.6] Recommendation ITU-T Y.1910: "IPTV architecture document".
[i.7] ETSI TS 126 234 (V9.3.0): "Universal Mobile Telecommunications System (UMTS); LTE;
Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs
(3GPP TS 26.234 version 9.3.0 Release 9)".
[i.8] Recommendation ITU-T Y.2019: "Content delivery functional architecture in NGN".
[i.9] ETSI TS 126 237: "Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast
Service (MBMS) User Service; Protocols (3GPP TS 26.237)".
[i.10] ISO/IEC 23009-1: "Dynamic Adaptive Streaming over HTTP".
ETSI
7 ETSI TR 102 688-9 V1.1.1 (2013-07)
[i.11] ISO 14721:2003: "OAIS (Open Archival Information System) Reference model".
[i.12] ISO 20652:2006: "PAIMAS (Producer-Archive interface methodology abstract standard)".
[i.13] ETSI TS 126 247 (V10.0.0): "Universal Mobile Telecommunications System (UMTS); LTE;
Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and
Dynamic Adaptive Streaming over HTTP (3GP-DASH) (3GPP TS 26.247 version 10.0.0
Release 10)".
[i.14] IETF RFC 3568: "Known Content Network (CN) Request-Routing Mechanisms".
[i.15] IETF RFC 3570: "Content Internetworking (CDI) Scenarios".
[i.16] IETF RFC 3143: "Known HTTP Proxy/Caching Problems".
[i.17] Draft-pantos-http-live-streaming-01.
NOTE: Available at http://tools.ietf.org/html/draft-pantos-http-live-streaming-01.
[i.18] Draft-pantos-http-live-streaming-06.
NOTE: Available at http://tools.ietf.org/html/draft-pantos-http-live-streaming-06.
[i.19] ATIS-0800007: "IPTV High Level Architecture".
[i.20] IETF draft-bertrand-cdni-experiments.
NOTE: Available at http://tools.ietf.org/html/draft-bertrand-cdni-experiments-02 .
[i.21] IETF draft-bertrand-cdni-use-cases.
NOTE: Available at http://tools.ietf.org/html/draft-ietf-cdni-use-cases-08.
[i.22] IETF draft-davie-cdni-framework.
NOTE: Available at http://tools.ietf.org/html/draft-davie-cdni-framework-01 .
[i.23] IETF draft-deventer-cdni-content-terminology.
NOTE: Available at http://tools.ietf.org/html/draft-deventer-cdni-content-terminology-00 .
[i.24] IETF draft-ietf-cdni-problem-statement.
NOTE: Available at http://tools.ietf.org/html/draft-ietf-cdni-problem-statement-08 .
[i.25] IETF draft-jenkins-cdni-names.
NOTE: Available at http://tools.ietf.org/html/draft-jenkins-cdni-names-00.
[i.26] IETF draft-jenkins-cdni-problem-statement.
NOTE: Available at http://tools.ietf.org/html/draft-ietf-cdni-problem-statement-03.
[i.27] IETF draft-lefaucheur-cdni-requirements.
NOTE: Available at http://tools.ietf.org/html/draft-lefaucheur-cdni-requirements-02 .
[i.28] IETF draft-ma-cdni-publisher-use-cases.
NOTE: Available at http://tools.ietf.org/html/draft-ma-cdni-publisher-use-cases-00.
[i.29] IETF draft-peterson-cdni-strawman.
NOTE: Available at http://tools.ietf.org/html/draft-peterson-cdni-strawman-00.
ETSI
8 ETSI TR 102 688-9 V1.1.1 (2013-07)
[i.30] IETF draft-stiemerling-cdni-routing-cons.
NOTE: Available at http://tools.ietf.org/html/draft-stiemerling-cdni-routing-cons-00.
[i.31] IETF draft-thompson-cdni-atis-scenarios.
NOTE: Available at http://tools.ietf.org/html/draft-thompson-cdni-atis-scenarios-00.
[i.32] IETF draft-watson-cdni-use-cases.
NOTE: Available at http://tools.ietf.org/html/draft-watson-cdni-use-cases-00.
[i.33] IETF draft-xiaoyan-cdni-requestrouting.
NOTE: Available at http://tools.ietf.org/html/draft-xiaoyan-cdni-requestrouting-01.
[i.34] IETF draft-zhou-cdni-use-case.
NOTE: Available at http://tools.ietf.org/html/draft-zhou-cdni-use-case-01.
[i.35] IETF Distribution Requirements for Content Internetworking.
NOTE: Available at http://tools.ietf.org/html/draft-amini-cdi-distribution-reqs-02 .
[i.36] IETF Security Threat for Content Internetworking.
NOTE: Available at http://tools.ietf.org/html/draft-ietf-cdi-threat-00.
[i.37] CableLabs MD-SP-ADI1.1-I04-060505: "CableLabs® Asset Distribution Interface Specification
Version 1.1".
[i.38] OIPF Volume 1 - Overview, release 2.
NOTE: Available at http://www.oipf.tv/specifications.
[i.39] OIPF Services and functions for Release 2.
NOTE: Available at http://www.oipf.tv/specifications.
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
Content Delivery Infrastructures (CDI): system of equipments and networks which role is to ensure efficient delivery
of Content to clients
NOTE: Content Delivery Networks are typical examples.
Content Delivery Network (CDN): system of computers containing copies of data, placed at various points in a
network so as to maximize bandwidth for access to the data from clients throughout the network
NOTE: Also known as Content Distribution Network (CDN).
content delivery: describes the delivery of Content Items over a delivery medium such as broadcasting or the Internet
content distribution: act of moving content between CDNs
content ingestion: act of introducing content (and associated data) into the Content Delivery Infrastructure
content item: piece of media "content" such as audio or video or computer software
ETSI
9 ETSI TR 102 688-9 V1.1.1 (2013-07)
content preparation: act of preparing content and metadata before its ingestion into a CDN
progressive download: type of streaming in which the audio or video file begins to play after a certain minimum
amount of data has been transferred, rather than requiring the entire file to be downloaded before playback starts
web cache: caching of web documents (e.g. HTML pages, images, video, etc.) to reduce bandwidth usage, server load
and perceived lag
NOTE: A web cache stores copies of documents passing through it; subsequent requests may be satisfied from
the cache if certain conditions are met.
web proxy: in computer networks, server (a computer system or an application program) that acts as an intermediary
for requests from clients seeking resources from other servers
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADI CableLabs Asset Distribution Interface
BCAST Broadcast Services (OMA)
CCF Cluster Controller Function
CD&LCF Content Distribution & Location Control Functions
CD&SF Content Delivery & Storage Functions
CDI Content Delivery Infrastructure
CDN Content Delivery Network
CDNCF Content Delivery Network Control Function
CDN-I Content Delivery Network Interconnection
CN Content Network
CORBA Common Object Request Broker Architecture
DASH Dynamic Adaptive Streaming over HTTP
DCD Dynamic Content Delivery (OMA)
DTG Digital TV Group
FFS For Further Study
FTP File Transfer Protocol
GSI Global Standards Initiative
HTTP Hyper Text Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IIF Interoperability Forum
IMS IP Multimedia Subsystem
IP Internet Protocol
IPTV Internet Protocol television
ITF IPTV Terminal Function
MCD Media Content Delivery
MPEG The Moving Picture Experts Group
NGN Next Generation Network
OAIS Open Archival Information System
OIPF Open IPTV Forum
OMA Open Mobile Alliance
PAIMAS Producer-Archive Interface Methodology Abstract Standard
PIM Personal Information Manager
RTMP Real Time Messaging Protocol
RTP Real-Time Protocol
RTSP Real-Time Streaming Protocol
SDP Service Delivery Platform
SIP Session Initiation Protocol
STB Set Top Box
TV TeleVision
UDP User Datagram Protocol
UE User equipment
URI Uniform Ressource Identifier
VOD Video On Demand
ETSI
10 ETSI TR 102 688-9 V1.1.1 (2013-07)
4 Role of Content Delivery Infrastructures
The role of Content Delivery Infrastructure is to efficiently, scalably and with adequate performance and timeliness
distribute content items to final customers.
Content Injection
Content
Reporting
CDI
User
Content
Preparation
WWW
Delivery
Figure 1: CDN in context
CDIs interact with two main entities: Content Provision on the upstream and Clients (users) on the downstream.
CDIs get their content from an upstream source: the Content Provision. The Content Provision typically injects content
into the CDI and extracts or receives reports on content consumption.
The role of the CDI is to respond to user requests for given pieces of content. The "Content Delivery" relationship is
constrained by what protocols clients implement.
Alternatively, the CDI can retrieve content from the internet on behalf of the client, thus behaving like a Web Proxy.
5 Use cases and Requirements
This clause gathers use case and requirements from earlier MCD documents (notably [i.2]) and adds more elements that
were derived from a more precise understanding of the content delivery landscape.
5.1 Requirements from Content Providers
The following requirements are being abstracted from the "Needs of content Providers" document [i.3]:
• R1: Support of Content access through a Content Portal
• R2: Support for protected content delivery, support for different Content Protection Mechanisms
• R3: Support for content delivery reporting mechanisms (optionally qualified by destination, time, etc.)
• R4: Support for file-based and stream-based content delivery
• R5: Support for Progressive Download and Adaptive Streaming
• R6: Support of a mechanism to remove content items from the CDI
• R7: Support for joint delivery of Metadata and Content
• R8: Support for control of delivery based on geographic location criteria
• R9: Support for Push and Pull models of content provision
• R10: Content Format neutrality, including content encapsulation and content protection
• R11: Support for Multicast Delivery
ETSI
11 ETSI TR 102 688-9 V1.1.1 (2013-07)
5.2 Specific Use Cases
The content Delivery Infrastructure should satisfy the following use cases:
User
• UC1: Operator content Live Streaming: an operator offers content for live streaming, the user retrieves the
content from the CDI as it is being played
• UC2: Internet content Live Streaming: an item of content is offered by an internet content provider, the user
retrieves the content from the CDI as it is being played
• UC3: Operator content downloading: an operator offers content download, the user retrieves the content from
the CDI for later consumption
• UC4: Internet content downloading: an item of content is offered by an internet content provider, the user
retrieves the content from the CDI for later consumption
• UC5: Interconnection of CDNs for wide distribution
• UC6: Interoperable Content Injection
• UC7: Mobile streaming: an operator offers content for live streaming, the mobile user retrieves the content
from the CDI as it is being played, through the mobile network
CDN Interconnection Use Cases should be looked up in annex A of [i.5].
5.3 Specific Requirements
The following requirements should be satisfied by the Content Delivery Infrastructure:
Network:
• RN01: Should work on basic IP networks
• RN02: Should be portable on different network infrastructures (ITU-T or ETSI NGN, 3GPP, IETF, etc.)
• RN03: Should not require deep integration with a specific underlying infrastructure
• RN04: Should not unnecessarily prescribe CDN implementation
• RN05: Should support delivery to mobile terminals as well as fixed terminals
• RN06: Should optionally support specific delivery modes for mobile terminals
• RN07: Should optionally support QoS for delivery of content to the user
• RN08: Should not expose QoS in the user interface
• RN09: Should reuse existing protocols to the maximum possible extent
• RN10: Should be reusable for different applications
User-related:
• RU1: Should support basic delivery protocols: HTTP and optionally RTSP/RTP
• RU2: Should support progressive download and Adaptive Streaming delivery modes where applicable
• RU3: Should support trick modes for Content Delivery
• RU4: Should support geographic proximity Content Delivery
• RU5: Should support mechanisms for request routing (i.e. allowing requests to be transferred to different
entities to improve the operation efficiency)
ETSI
12 ETSI TR 102 688-9 V1.1.1 (2013-07)
Content:
• RC1: Should support CDI operator content
• RC2: Should support content accessed over the wwweb (through http) as an option
• RC3: Should be agnostic to content format:
- Accommodate different codecs
- Accommodate different content protection mechanisms
- Reduce need for processing metadata
Content Injection:
• CI1: Should allow Injection of Content Items in file format
• CI2: Should allow injection of Content in Stream Format
• CI3: Should provide clear indication of injection status
• CI4: Should provide the information necessary to access the content (e.g. URI)
• CI5: Should enable reporting of Content Access statistics for a given Content Item
CDN Interconnection:
• RI1: Should support interconnection of Identical or Heterogeneous CDNs:
- Should support CDN federation use cases
- Should support CDN resource sharing use cases
6 Taxonomy of CDNs
There are different types of Content Delivery networks, that can be differentiated on their main purpose, where and how
they obtain content items, how they are controlled and deliver the content. Some criteria are the following:
• Origin of the content (Internet, Internally stored content, Third party, etc.)
• Destination and protocol of the content (IPTV STB with specific protocols, HTTP browser, etc.)
• Other criteria
The categories described here are non-exclusive and can be combined to form a more elaborate form of CDN.
Content Origin
Internet Stored
Content Destination IPTV STB IPTV cache IPTV CDN
Generic HTTP client Proxy cache HTTP CDN
Figure 2
6.1 Traditional Internet CDN
The category for Traditional Internet CDNs encompass the common Internet commercial WWW content hosting
solutions.
Functionally, they receive HTTP requests directly from users and serve those requests from a conglomerate of
geographically distributed servers.
The Input interface is not specified, though it can be composed of different interfaces based on standard protocols
(HTTP and HTTPS, FTP, etc.). Sometimes protocols are supported for specific purposes (Adobe® RTMP, etc.).
ETSI
13 ETSI TR 102 688-9 V1.1.1 (2013-07)
The reporting interface is even less specified and can range from tailored HTTP+HTML to raw logs or text files
obtained in a variety of ways.
6.2 Operator VOD CDNs
Operator VOD CDNs are specialized for the delivery of stored content items and serve those requests from a
conglomerate of geographically distributed servers within an operator network.
In many cases, VOD CDNs are integrated within an IPTV system and are controlled by system-specific protocols (SIP,
RTSP, etc.)
6.3 Caches
Caches (often designated in web architectures as proxy-caches because the cache impersonates servers) are mediators
between the internet and users, storing popular content items to provide better response times and lighten the load on
the connection towards the internet.
7 State of the art
This clause goes through the main standards and proprietary solution elements related to Content Delivery.
7.1 Existing and upcoming CDN Architecture Standards
7.1.1 ITU-T IPTV GSI, SG13 and SG16
Starting with the IPTV Focus Group, ITU-T has developed a "Content Delivery Functions" Functional Block which role
is essentially an IPTV-targeted CDN (largely for the support of operator-hosted VOD) that was integrated in its IPTV
architecture document [i.6]. More recently this CDN was precised in a specific recommendation on CDN functional
architecture [i.8].
ETSI
14 ETSI TR 102 688-9 V1.1.1 (2013-07)

Figure 3: Recommendation ITU-T Y.1910 [i.6] Overall Architecture
The CDN functional block is depicted with several sub-components and internal interfaces.

Figure 4: Recommendation ITU-T Y.2019 [i.8] detailed Content Distribution Architecture
ETSI
15 ETSI TR 102 688-9 V1.1.1 (2013-07)
The above figures depict the architecture as in Recommendation ITU-T Y.1910 [i.6] (figure 3) and as in
Recommendation ITU-T Y.2019 [i.8] (figure 4). It should be noted that Recommendation ITU-T Y.2019 [i.8] does not
redefine or change the external interfaces defined in Recommendation ITU-T Y.1910 [i.6] but adds internal components
and interfaces.
The external interfaces to the CDN components are:
• Service Control:
- S1 (S1' is identical to S1) used to forward the service signalling messages, e.g. service requests, content
resource requests, between the ITF/IPTV application functions and the CD&LCF. For the IMS variant,
S1 is defined as SIP. For other variants, the protocol is not specified in
Recommendation ITU-T Y.1910 [i.6] (FFS).
- E4 used to exchange messages for requesting and delivering error recovery information. Protocol not
specified in Recommendation ITU-T Y.1910 [i.6] (FFS).
- E6 used to exchange content control messages, e.g. video recording commands. Defined as RTSP in
Recommendation ITU-T Y.1910 [i.6].
• Input (Ingestion):
- A2 used by the IPTV applications functional block to request service parameters from CD&LCF.
Protocol not specified in Recommendation ITU-T Y.1910 [i.6] (FFS).
- C1 used to facilitate content preparation functions to configure policies such as content distribution rules,
selection criteria, etc. in the CD&LCF. Protocol not specified in Recommendation ITU-T Y.1910 [i.6]
(FFS).
- C2 used to transfer content from content preparation functions to CD&SF. Protocol not specified in
Recommendation ITU-T Y.1910 [i.6] (FFS).
• Transport:
- Uc (also called Ud in Recommendation ITU-T Y.1910 [i.6]) used by the CD&SF to deliver content
streams in unicast mode. Defined as RTP over UDP in Recommendation ITU-T Y.1910 [i.6].
- Mc used to pass information to allow for the dynamic computation, establishment and maintenance of
multicast trees. Defined as PIM in Recommendation ITU-T Y.1910 [i.6].
- Md used by the CD&SF to deliver content streams in multicast mode. Defined as RTP over UDP in
Recommendation ITU-T Y.1910 [i.6].
7.1.1.1 Assessment
Many of the external interfaces appear to be in line with the CDI requirements (notably the Transport interfaces Uc/Ud
MC/Md, possibly C2), however some introduce coupling that might be contrary to several requirements:
• S1 is based on IMS in one of the variants, which introduces coupling with an IMS subsystem which may
contradicts the requirement on network architecture neutrality.
• E4 introduces a dependency on external error recovery mechanisms.
• A2 and C1 introduce coupling between the content preparation and CDN functions. The internal structure
appears to constrain the implementation in contradiction with requirement RN04.
There is no explicit consideration of the requirement to interconnect CDNs between different operators, though there is
provision of hierarchical relationships between CDN components. This appears to prevent CDN interconnection of
CDN components not compliant with Recommendation ITU-T Y.2019 [i.8].
However it may be possible to specify a subset of Y.1910 that would be appropriate for the purpose of CDI, if it is
complemented with a heterogeneous CDN interconnection addition. That subset should concentrate on the external
interfaces while omitting the specification of internal mechanisms and reference points. Because most of the
specification in Recommendation ITU-T Y.2019 [i.8] relates to internal coordination mechanisms and protocols, there
is little that can be considered appropriate for CDI whose purpose is mainly external interfaces to the CDI.
ETSI
16 ETSI TR 102 688-9 V1.1.1 (2013-07)
7.1.2 ETSI TISPAN
ETSI TISPAN started considering Content Delivery Networks as addition to its Release 3 IPTV specification. Starting
first as an IPTV-oriented CDN for VOD in the IMS IPTV, it has grown in every direction to cover IMS-IPTV and
dedicated IPTV, but also Internet-service and even CDN interconnection. The goal was provide single CDN for both
TISPAN NGN based IPTV architecture as alternative and from scalability reason to media functions (media delivery
and media control).
TS 182 019 [i.3] (Content Delivery Network (CDN) architecture - Interconnection with TISPAN IPTV architectures)
describe architectural principles of a CDN as shown in figure 5.
Content Acquisition
Content Ingestion
Billing
Content Deployment
Accounting
CDN
Request Routing
Replica server 1 Replica server M

Figure 5: Architectural components of a CDN
ETSI
17 ETSI TR 102 688-9 V1.1.1 (2013-07)
Content Delivery Network
COF
Yv
Qq'
ALF
Qq
Qq
Cu/Qc
CDNCF
CDNCF
Yq
IPTV Subsystem
Yy
Ys Ys
Yy
Ct Cluster
CCF
Cluster
CCF
Yp
Xc’
Yp
Yp
Cf’
Cf Cf
Xd'
UE CDF
CDF
CDF
Xc’’
Figure 6: Overall view of the TISPAN CDN architecture
Figures 5 and 6 show in order: the CDN architecture and its relationship to the IPTV subsystem and UEs, the different
CDN functional entities.
TISPAN CDN architecture describe a number of external Interfaces that are specified in [i.3]:
• Interfaces to IPTV service platforms (Cu Qc Ct):
- Service control related interface, in charge of initiating the delivery the requested content to the UE (Cu,
identical to Y2 in IMS-based IPTV, identical to Sa in Integrated IPTV)
- Management related interface, in charge of administration and provisioning tasks
Allows the IPTV subsystem to query the CDNCF for the CCF to be contacted for a content (Qc)
Carries IPTV service control signalling originating from the IPTV subsystem to CCF (Ct, identical
to Y2 in IMS-based IPTV, identical to Sa in Integrated IPTV)
• Interfaces to UE:
- Content control related interface (Xc' and Xc", functionally equivalent to RTSP)
- Media delivery interface(Xd'): Delivery information is sent to the UE, after which delivery is initiated
and completed by the UE
• Interface towards content distribution systems:
- Service control related interface
- Media delivery interface
ETSI
18 ETSI TR 102 688-9 V1.1.1 (2013-07)
7.1.2.1 Assessment
Many of the external interfaces appear to be in line with the CDI requirements, however some introduce coupling that
might be contrary to several requirements:
• Y2 ties to the IMS subsystem
• In effect each outside component needs to be aware of the existence of multiple internal CDN components,
possibly requiring specific connection setup operations:
- Integrated IPTV subsystem needs to know about the CDNCF (for Qc) and CCF (for Ct)
- UE needs to know about CCF (for XC') and Cf (for Xc" otherwise identical to Xc' and Xd')
The internal structure appears to constrain the implementation in contradiction with requirement RN04, but this simply
means that the TISPAN CDN can be considered a specific implementation architecture for the CDI, at least for the
subpart that not controlled with IMS.
There is an explicit provision for CDN interconnection between TISPAN CDNs. This could prevent interconnection of
CDNs which internal architecture and implementation is significantly different from TISPAN's. Should TISPAN also
support an heterogeneous CDN interconnection interface, then this concern would become moot.
At this point, there are no content ingestion interfaces specified, though it is mentioned in figure 1.
It appears possible to specify a subset of TISPAN WI2076 CDN that would be appropriate for the purpose of CDI, if it
is complemented with a heterogeneous CDN interconnection addition. That subset would concentrate on the external
interfaces while omitting the specification of internal mechanisms and reference points. The exposure of different
internal components to the outside interfaces should be hidden to address requirement RN04.
7.1.3 ATIS IIF
ATIS IIF has worked on an architecture that was close to that of Recommendation ITU-T Y.1910 [i.6] and inherited a
similar Content Delivery Functional Block which is described in ATIS-0800007 [i.19], IPTV High Level Architecture.
The specification with the best level of detail is the Content On Demand Working Text [i.6].
As with the ITU-T specifications, ATIS also retain an IMS-based and a non-IMS-based variant. The main diagram
differs from ITU-T's by putting client functions on the right-hand side.
External Interfaces to the Content Delivery Component:
• End User Functions:
- E6, used to exchange content control signalling information (e.g. session setup and teardown in the
redirect case, play, pause, fast forward, rewind, download) between the ITF and the CD&SF
• Service Control Functions:
- S1, used by the CoD Service Control Function to locate an instance of the CD&SF capable of delivering
the requested content to the ITF
- S5, used to exchange session management information between the CoD Service Control Function and
the CD&SF
• Application Functions:
- C1, used by the Content Origin Function to notify the CD&LCF of relevant information associated with
an asset
- C2, used by the Content Receiving Function to retrieve content from the Content Origin Function
- C4, used to request security information for the purposes of session-based encryption of the content, if
applicable
ETSI
19 ETSI TR 102 688-9 V1.1.1 (2013-07)
• Transport Functions:
- Ud, used by the CD&SF to deliver content streams in unicast mode

Figure 7: ATIS IIF Overall Architecture
7.1.3.1 Assessment
Many of the external interfaces appear to be in line with the CDI requirements, however some introduce coupling that
might be contrary to several requirements:
• C4 exposes content encryption functions, in contraction with the CDI requirement on content format
neutrality.
• S1 exposes content location functions.
The internal structure appears to constrain the implementation in contradiction with requirement RN04.
Overall the CDN appears to have been thought as tightly integrated within an IPTV system, which makes
implementation more constrained and limits the applicability to more architecture-neutral systems.
There is no explicit provision for CDN interconnection.
At this point, there are no content ingestion interfaces specified, though it is mentioned in the overall diagram.
However it may be possible to specify a subset of this CDN that would be appropriate for the purpose of CDI, if it is
complemented with a heterogeneous CDN interconnection addition. That subset should concentrate on the external
interfaces while omitting the specification of internal mechanisms and reference points. The exposure of different
components to the outside interfaces should be hidden.
ETSI
20 ETSI TR 102 688-9 V1.1.1 (2013-07)
7.1.4 Open IPTV Forum
The OpenIPTVForum has introduced a Content Delivery Component for provision of VOD in the Enhanced Managed
Profile based on IMS.
Figure 8: Overall OIPF Architecture
7.1.4.1 Assessment
The CDN in the OpenIPTVForum is closely linked with the "Authentication and Session Management" Component
(which refers to the IMS) and appears meant to serve only the Extended Managed Profile for the provision of operator
VOD services. This is compounded by the fact that Control interfaces are based on SIP.
This means that the OIPF specifications OIPF Volume 1 - Overview, release 2 [i.38] and OIPF Services and functions
for Release 2 [i.39] might not be able to support clients implementing simple internet-based interfaces (as included in
the OIPF Open Internet Profile, or even the Baseline Managed Profile), which is in contradiction with the requirements
...