7. IPTV and ICN
7.1. IPTV Challenges
IPTV refers to the delivery of quality content broadcast over the
Internet and is typically associated with strict quality
requirements, i.e., with a perceived latency of less than 500 ms and
a packet loss rate that is multiple orders lower than the current
loss rates experienced in the most commonly used access networks (see
[ATIS-IIF]). We can summarize the major challenges for the delivery
of IPTV service as follows.
Channel change latency represents a major concern for the IPTV
service. Perceived latency during channel change should be less than
500 ms. To achieve this objective over the IP infrastructure, we
have multiple choices:
i receive fast unicast streams from a dedicated server (most
effective but not resource efficient);
ii connect to other peers in the network (efficiency depends on
peer support, effective and resource efficient, if also
supported with a dedicated server); and
iii connect to multiple multicast sessions at once (effective but
not resource efficient and depends on the accuracy of the
prediction model used to track user activity).
The second major challenge is the error recovery. Typical IPTV
service requirements dictate the mean time between artifacts to be
approximately 2 hours (see [ATIS-IIF]). This suggests the perceived
loss rate to be less than or equal to 10^-7. Current IP-based
solutions rely on the following proactive and reactive recovery
techniques: (i) joining the Forward Error Correction (FEC) multicast
stream corresponding to the perceived packet loss rate (not
efficient, as the recovery strength is chosen based on worst-case
loss scenarios); (ii) making unicast recovery requests to dedicated
servers (requires active support from the service provider); (iii)
probing peers to acquire repair packets (finding matching peers and
enabling their cooperation is another challenge).
7.2. ICN Benefits for IPTV Delivery
ICN presents significant advantages for the delivery of IPTV traffic.
For instance, ICN inherently supports multicast and allows for quick
recovery from packet losses (with the help of in-network caching).
Similarly, peer support is also provided in the shape of in-network
caches that typically act as the middleman between two peers,
therefore enabling earlier access to IPTV content.
However, despite these advantages, delivery of IPTV service over ICNs
brings forth new challenges. We can list some of these challenges as
o Messaging overhead: ICN is a pull-based architecture and relies on
a unique balance between requests and responses. A user needs to
make a request for each Data packet. In the case of IPTV, with
rates up to (and likely to be) above 15 Mbps, we observe
significant traffic upstream to bring those streams. As the
number of streams increases (including the same session at
different quality levels and other formats), so does the burden on
the routers. Even if the majority of requests are aggregated at
the core, routers close to the edge (where we observe the biggest
divergence in user requests) will experience a significant
increase in overhead to process these requests. The same is true
at the user side, as the uplink usage multiplies in the number of
sessions a user requests (for instance, to minimize the impact of
o Cache control: As the IPTV content expires at a rapid rate (with a
likely expiry threshold of 1 s), we need solutions to effectively
flush out such content to also prevent degradation impact on other
cached content, with the help of intelligently chosen naming
conventions. However, to allow for fast recovery and optimize
access time to sessions (from current or new users), the timing of
such expirations needs to be adaptive to network load and user
demand. However, we also need to support quick access to earlier
content, whenever needed; for instance, when the user accesses the
rewind feature (note that in-network caches will not be of
significant help in such scenarios due to the overhead required to
maintain such content).
o Access accuracy: To receive the up-to-date session data, users
need to be aware of such information at the time of their request.
Unlike IP multicast, since the users join a session indirectly,
session information is critical to minimize buffering delays and
reduce the startup latency. Without such information, and without
any active cooperation from the intermediate routers, stale data
can seriously undermine the efficiency of content delivery.
Furthermore, finding a cache does not necessarily equate to
joining a session, as the look-ahead latency for the initial
content access point may have a shorter lifetime than originally
intended. For instance, if the user that has initiated the
indirect multicast leaves the session early, the requests from the
remaining users need to experience an additional latency of one
RTT as they travel towards the content source. If the startup
latency is chosen depending on the closeness to the intermediate
router, going to the content source in-session can lead to
It should be noted that IPTV includes more than just multicast. Many
implementations include "trick plays" (fast forward, pause, rewind)
that often transform a multicast session into multiple unicast
sessions. In this context, ICN is beneficial, as the caching offers
an implicit multicast but without tight synchronization constraints
in between two different users. One user may rewind and start
playing forward again, thus drawing from a nearby cache of the
content recently viewed by another user (whereas in a strict
multicast session, the opportunity of one user lagging off behind
would be more difficult to implement).
8. Digital Rights Management in ICN
This section discusses the need for DRM functionalities for
multimedia streaming over ICN. It focuses on two possible
approaches: modifying Authentication, Authorization, and Accounting
(AAA) to support DRM in ICN and using Broadcast Encryption.
It is assumed that ICN will be used heavily for digital content
dissemination. It is vital to consider DRM for digital content
distribution. In today's Internet, there are two predominant classes
of business models for on-demand video streaming. The first model is
based on advertising revenues. Non-copyright protected (usually
User-Generated Content (UGC)) content is offered by large
infrastructure providers like Google (YouTube) at no charge. The
infrastructure is financed by spliced advertisements into the
content. In this context, DRM considerations may not be required,
since producers of UGC may only strive for the maximum possible
dissemination. Some producers of UGC are mainly interested in
sharing content with their families, friends, colleges, or others and
have no intention making a profit. However, the second class of
business model requires DRM, because these entities are primarily
profit oriented. For example, large on-demand streaming platforms
(e.g., Netflix) establish business models based on subscriptions.
Consumers may have to pay a monthly fee in order to get access to
copyright-protected content like TV series, movies, or music. This
model may be ad supported and free to the content consumer, like
YouTube Channels or Spotify, but the creator of the content expects
some remuneration for his work. From the perspective of the service
providers and the copyright owners, only clients that pay the fee
(explicitly or implicitly through ad placement) should be able to
access and consume the content. Anyway, the challenge is to find an
efficient and scalable way of access control to digital content,
which is distributed in ICNs.
8.1. Broadcast Encryption for DRM in ICN
This section discusses Broadcast Encryption (BE) as a suitable basis
for DRM functionalities in conformance to the ICN communication
paradigm (network-inherent caching, considered the advantage of BE,
will be highlighted).
In ICN, Data packets can be cached inherently in the network, and any
network participant can request a copy of these packets. This makes
it very difficult to implement an access control for content that is
distributed via ICN. A naive approach is to encrypt the transmitted
data for each consumer with a distinct key. This prohibits everyone
other than the intended consumers from decrypting and consuming the
data. However, this approach is not suitable for ICN's communication
paradigm, since it would reduce the benefits gained from the inherent
network caching. Even if multiple consumers request the same
content, the requested data for each consumer would differ using this
approach. A better, but still insufficient, idea is to use a single
key for all consumers. This does not destruct the benefits of ICN's
caching ability. The drawback is that if one of the consumers
illegally distributes the key, the system is broken; any entity in
the network can access the data. Changing the key after such an
event is useless since the provider has no possibility to identify
the illegal distributor. Therefore, this person cannot be stopped
from distributing the new key again. In addition to this issue,
other challenges have to be considered. Subscriptions expire after a
certain time, and then it has to be ensured that these consumers
cannot access the content anymore. For a provider that serves
millions of daily consumers (e.g., Netflix), there could be a
significant number of expiring subscriptions per day. Publishing a
new key every time a subscription expires would require an unsuitable
amount of computational power just to re-encrypt the collection of
A possible approach to solve these challenges is BE [Fiat94] as
proposed in [Posch13]. From this point on, this section will focus
only on BE as an enabler for DRM functionality in the use case of ICN
video streaming. This subsection continues with the explanation of
how BE works and shows how BE can be used to implement an access
control scheme in the context of content distribution in ICN.
BE actually carries a misleading name. One might expect a concrete
encryption scheme. However, it belongs to the family of key
management schemes. These schemes are responsible for the
generation, exchange, storage, and replacement of cryptographic keys.
The most interesting characteristics of BE schemes are:
o BE schemes typically use a global trusted entity called the
Licensing Agent (LA), which is responsible for spreading a set of
pre-generated secrets among all participants. Each participant
gets a distinct subset of secrets assigned from the LA.
o The participants can agree on a common session key, which is
chosen by the LA. The LA broadcasts an encrypted message that
includes the key. Participants with a valid set of secrets can
derive the session key from this message.
o The number of participants in the system can change dynamically.
Entities may join or leave the communication group at any time.
If a new entity joins, the LA passes on a valid set of secrets to
that entity. If an entity leaves (or is forced to leave) the LA
revokes the entity's subset of keys, which means that it cannot
derive the correct session key anymore when the LA distributes a
o Traitors (entities that reveal their secrets) can be traced and
excluded from ongoing communication. The algorithms and
preconditions to identify a traitor vary between concrete BE
This listing already illustrates why BE is suitable to control the
access to data that is distributed via an ICN. BE enables the usage
of a single session key for confidential data transmission between a
dynamically changing subset or network participants. ICN caches can
be utilized since the data is encrypted only with a single key known
by all legitimate clients. Furthermore, traitors can be identified
and removed from the system. The issue of re-encryption still exists
because the LA will eventually update the session key when a
participant should be excluded. However, this disadvantage can be
relaxed in some way if the following points are considered:
o The updates of the session key can be delayed until a set of
compromised secrets has been gathered. Note that secrets may
become compromised because of two reasons: first, a traitor could
have illegally revealed the secret; second, the subscription of an
entity expired. Delayed revocation temporarily enables some
illegitimate entities to consume content. However, this should
not be a severe problem in home entertainment scenarios. Updating
the session key in regular (not too short) intervals is a good
trade- off. The longer the interval lasts, the less computational
resources are required for content re-encryption and the better
the cache utilization in the ICN will be. To evict old data from
ICN caches that have been encrypted with the prior session key,
the publisher could indicate a lifetime for transmitted packets.
o Content should be re-encrypted dynamically at request time. This
has the benefit that untapped content is not re-encrypted if the
content is not requested during two session key update; therefore,
no resources are wasted. Furthermore, if the updates are
triggered in non-peak times, the maximum amount of resources
needed at one point in time can be lowered effectively since in
peak times generally more diverse content is requested.
o Since the amount of required computational resources may vary
strongly from time to time, it would be beneficial for any
streaming provider to use cloud-based services to be able to
dynamically adapt the required resources to the current needs. In
regard to a lack of computation time or bandwidth, the cloud
service could be used to scale up to overcome shortages.
Figure 4 shows the potential usage of BE in a multimedia delivery
framework that builds upon ICN infrastructure and uses the concept of
dynamic adaptive streaming, e.g., DASH. BE would be implemented on
the top to have an efficient and scalable way of access control to
the multimedia content.
+--------Multimedia Delivery Framework--------+
| Technologies Properties |
| +----------------+ +----------------+ |
| | Broadcast |<--->| Controlled | |
| | Encryption | | Access | |
| +----------------+ +----------------+ |
| |Dynamic Adaptive|<--->| Multimedia | |
| | Streaming | | Adaptation | |
| +----------------+ +----------------+ |
| | ICN |<--->| Cacheable | |
| | Infrastructure | | Data Chunks | |
| +----------------+ +----------------+ |
Figure 4: A Potential Multimedia Framework Using BE8.2. AAA-Based DRM for ICN Networks
Recently, a novel approach to DRM has emerged to link DRM to usual
network management operations, hence linking DRM to AAA services.
ICN provides the abstraction of an architecture where content is
requested by name and could be served from anywhere. In DRM, the
content provider (the origin of the content) allows the destination
(the end-user account) to use the content. The content provider and
content storage/cache are at two different entities in ITU Carrier
Code (ICC); for traditional DRM, only source and destination count
and not the intermediate storage. The proposed solution allows the
provider of the caching to be involved in the DRM policies using
well-known AAA mechanisms. It is important to note that this
solution is compatible with the proposal of the BE, proposed earlier
in this document. The BE proposes a technology, as this solution is
With the proposed AAA-based DRM, when content is requested by name
from a specific destination, the request could link back to both the
content provider and the caching provider via traditional AAA
mechanisms and trigger the appropriate DRM policy independently from
where the content is stored. In this approach, the caching, DRM, and
AAA remain independent entities but can work together through ICN
mechanisms. The proposed solution enables extending the traditional
DRM done by the content provider to jointly being done by content
provider and network/caching provider.
The solution is based on the concept of a "token". The content
provider authenticates the end user and issues an encrypted token to
authenticate the named-content ID or IDs that the user can access.
The token will be shared with the network provider and used as the
interface to the AAA protocols. At this point, all content access is
under the control of the network provider and the ICN. The
controllers and switches can manage the content requests and handle
mobility. The content can be accessed from anywhere as long as the
token remains valid or the content is available in the network. In
such a scheme, the content provider does not need to be contacted
every time a named-content is requested. This reduces the load of
the content provider network and creates a DRM mechanism that is much
more appropriate for the distributed caching and Peer-to-Peer storage
characteristic of ICN networks. In particular, the content requested
by name can be served from anywhere under the only condition that the
storage/cache can verify that the token is valid for content access.
The solution is also fully customizable to both content and network
provider's needs as the tokens can be issued based on user accounts,
location, and hardware (Media Access Control (MAC) address, for
example) linking it naturally to legacy authentication mechanisms.
In addition, since both content and network providers are involved in
DRM policies, pollution attacks and other illegal requests for the
content can be more easily detected. The proposed AAA-based DRM is
currently under full development.
9. Future Steps for Video in ICN
The explosion of online video services, along with their increased
consumption by mobile wireless terminals, further exacerbates the
challenges of ICN mechanisms that leverage Video Adaptation. The
following sections present a series of research items derived from
these challenges, further introducing next steps for the subject.
9.1. Large-Scale Live Events
Distributing content, and video in particular, using local
communications in large-scale events such as sporting events in a
stadium, a concert, or a large demonstration, is an active area of
investigation and a potential use case where ICN would provide
Such use cases involve locating content that is generated on the fly
and requires discovery mechanisms in addition to sharing mechanisms.
The scalability of the distribution becomes important as well.
9.2. Video Conferencing and Real-Time Communications
Current protocols for video conferencing have been designed, and this
document takes input from them to identify the key research issues.
Real-time communications add timing constraints (both in terms of
delay and in terms of synchronization) to the scenario discussed
An Access Router (AR) and a Virtual Router (VR), and immersive
multimedia experiences in general, are clearly an area of further
investigation, as they involve combining multiple streams of data
from multiple users into a coherent whole. This raises issues of
multisource, multidestination multimedia streams that ICN may be
equipped to deal with in a more natural manner than IP, which is
9.3. Store-and-Forward Optimized Rate Adaptation
One of the benefits of ICN is to allow the network to insert caching
in the middle of the data transfer. This can be used to reduce the
overall bandwidth demands over the network by caching content for
future reuse, but it provides more opportunities for optimizing video
Consider, for instance, the following scenario: a client is connected
via an ICN network to a server. Let's say the client is connected
wirelessly to a node that has a caching capability, which is
connected through a WAN to the server. Further, assume that the
capacity of each of the links (both the wireless and the WAN logical
links) varies with time.
If the rate adaptation is provided in an end-to-end manner, as in
current mechanisms like DASH, then the maximal rate that can be
supported at the client is that of the minimal bandwidth on each
If, for instance, during Time Period 1 the wireless capacity is 1 and
the wired capacity is 2 and during Time Period 2 the wireless
capacity is 2 (due to some hotspot) and the wired capacity is 1 (due
to some congestion in the network), then the best end-to-end rate
that can be achieved is 1 during each period.
However, if the cache is used during Time Period 1 to pre-fetch 2
units of data, then during Time Period 2 there is 1 unit of data at
the cache and another unit of data that can be streamed from the
server; therefore, the rate that can be achieved is 2 units of data.
In this case, the average bandwidth rises from 1 to 1.5 over the two
This straw-man example illustrates a) the benefit of ICN for
increasing the throughput of the network and b) the need for the
special rate adaptation mechanisms to be designed to take advantage
of this gain. End-to-end rate adaptation cannot take advantage of
the cache availability. The authors of [Rainer16] showed that
buffer-based adaptation mechanisms can be one approach to tackle this
challenge. As buffer-based adaptation does not estimate the
available bandwidth resources (but solely considers the video buffer
fill state), measured bandwidth fluctuations caused by cache hits are
not existent. Therefore, they cannot negatively impact the
adaptation decisions (e.g., frequent representation switching).
9.4. Heterogeneous Wireless Environment Dynamics
With the ever-growing increase in online services being accessed by
mobile devices, operators have been deploying different overlapping
wireless access networking technologies. In this way, in the same
area, user terminals are within range of different cellular, Wi-Fi,
or even Worldwide Interoperability for Microwave Access (WiMAX)
networks. Moreover, with the advent of the Internet of Things (e.g.,
surveillance cameras feeding video footage), this list can be further
complemented with more-specific short-range technologies, such as
Bluetooth or ZigBee.
In order to leverage from this plethora of connectivity
opportunities, user terminals are coming equipped with different
wireless access interfaces, providing them with extended connectivity
opportunities. In this way, such devices become able to select the
type of access that best suits them according to different criteria,
such as available bandwidth, battery consumption, access to different
link conditions according to the user profile, or even access to
different content. Ultimately, these aspects contribute to the QoE
perceived by the end user, which is of utmost importance when it
comes to video content.
However, the fact that these users are mobile and using wireless
technologies also provides a very dynamic setting where the current
optimal link conditions at a specific moment might not last or be
maintained while the user moves. These aspects have been amply
analyzed in recently finished projects such as FP7 MEDIEVAL
[MEDIEVAL], where link events reporting on wireless conditions and
available alternative connection points were combined with video
requirements and traffic optimization mechanisms towards the
production of a joint network and mobile terminal mobility management
decision. Concretely, in [Fu13], link information about the
deterioration of the wireless signal was sent towards a mobility
management controller in the network. This input was combined with
information about the user profile, as well as of the current video
service requirements, and used to trigger the decrease or increase of
scalable video layers (adjusting the video to the ongoing link
conditions). Incrementally, the video could also be adjusted when a
new, better connectivity opportunity presents itself.
In this way, regarding Video Adaptation, ICN mechanisms can leverage
from their intrinsic multiple source support capability and go beyond
the monitoring of the status of the current link, thus exploiting the
availability of different connectivity possibilities (e.g., different
"interfaces"). Moreover, information obtained from the mobile
terminal's point of view of its network link, as well as information
from the network itself (i.e., load, policies, and others), can
generate scenarios where such information is combined in a joint
optimization procedure allowing the content to be forward to users
using the best available connectivity option (e.g., exploiting
management capabilities supported by ICN intrinsic mechanisms as in
In fact, ICN base mechanisms can further be exploited in enabling new
deployment scenarios such as preparing the network for mass requests
from users attending a large multimedia event (i.e., concert,
sports), allowing video to be adapted according to content, user and
network requirements, and operation capabilities in a dynamic way.
Enabling such scenarios requires further research, with the main
points highlighted as follows:
o how to develop a generic video services (and obviously content)
interface allowing the definition and mapping of their
requirements (and characteristics) into the current capabilities
of the network;
o how to define a scalable mechanism allowing either the video
application at the terminal or some kind of network management
entity, to adapt the video content in a dynamic way;
o how to develop the previous research items using intrinsic ICN
mechanisms (i.e., naming and strategy layers);
o how to leverage intelligent pre-caching of content to prevent
stalls and poor quality phases, which lead to a worse QoE for the
user: this includes, in particular, the usage in mobile
environments, which are characterized by severe bandwidth changes
as well as connection outages, as shown in [Crabtree13]; and
o how to take advantage of the multipath opportunities over the
heterogeneous wireless interfaces.
9.5. Network Coding for Video Distribution in ICN
An interesting research area for combining heterogeneous sources is
to use network coding [Montpetit13b]. Network coding allows for
asynchronous combining of multiple sources by having each of them
send information that is not duplicated by the other but that can be
combined to retrieve the video stream.
However, this creates issues in ICN in terms of defining the proper
rate adaptation for the video stream, securing the encoded data,
caching the encoded data, timeliness of the encoded data, overhead of
the network coding operations both in network resources and in added
buffering delay, etc.
Network coding has shown promise in reducing buffering events in
unicast, multicast, and P2P settings. [Medard12] considers
strategies using network coding to enhance QoE for multimedia
communications. Network coding can be applied to multiple streams,
but also within a single stream as an equivalent of a composable
erasure code. Clearly, there is a need for further investigation of
network coding in ICN, potentially as a topic of activity in the
9.6. Synchronization Issues for Video Distribution in ICN
ICN decouples the fetching of video chunks from their locations.
This means an audio chunk may be received from one network element
(cache/storage/server), a video chunk may be received from another,
while yet another chunk (say, the next one, or another layer from the
same video stream) may come from a third element. This introduces
disparity in the retrieval times and locations of the different
elements of a video stream that need to be played at the same (or
almost same) time. Synchronization of such delivery and playback may
require specific synchronization tools for video delivery in ICN.
Other aspects involve synchronizing:
o within a single stream, for instance, the consecutive chunks of a
single stream or the multiple layers of a layered scheme when
sources and transport layers may be different.
o re-ordering the packets of a stream distributed over multiple
sources at the video client, or ensuring that multiple chunks
coming from multiple sources arrive within an acceptable time
o multiple streams, such as the audio and video components of a
video stream, which can be received from independent sources; and
o multiple streams from multiple sources to multiple destinations,
such as mass distribution of live events. For instance, for live
video streams or video conferencing, some level of synchronization
is required so that people watching the stream view the same
events at the same time.
Some of these issues were addressed in [Montpetit13a] in the context
of social video consumption. Network coding, with traffic
engineering, is considered as a potential solution for
synchronization issues. Other approaches could be considered that
are specific to ICN as well.
Traffic engineering in ICN [Su14] [Chanda13] may be required to
provide proper synchronization of multiple streams.
10. Security Considerations
This is informational. There are no specific security considerations
outside of those mentioned in the text.
This document proposes adaptive video streaming for ICN, identified
potential problems, and presents the combination of CCN with DASH as
a solution. As both concepts, DASH and CCN, maintain several
elements in common, like, e.g., the content in different versions
being dealt with in segments, combination of both technologies seems
useful. Thus, adaptive streaming over CCN can leverage advantages
such as, e.g., efficient caching and intrinsic multicast support of
CCN, routing based on named-data URIs, intrinsic multilink and
multisource support, etc.
In this context, the usage of CCN with DASH in mobile environments
comes together with advantages compared to today's solutions,
especially for devices equipped with multiple network interfaces.
The retrieval of data over multiple links in parallel is a useful
feature, specifically for adaptive multimedia streaming since it
offers the possibility to dynamically switch between the available
links depending on their bandwidth capabilities, which are
transparent to the actual DASH client.
12.1. Normative References
[Rainer16] Rainer, B., Posch, D., and H. Hellwagner, "Investigating
the Performance of Pull-based Dynamic Adaptive Streaming
in NDN", IEEE Journal on Selected Areas in Communications
(J-SAC): Special Issue on Video Distribution over Future
Internet, Volume 34, Number 8,
DOI 10.1109/JSAC.2016.2577365, August 2016.
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements
of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
DOI 10.17487/RFC6972, July 2013,
12.2. Informative References
[ATIS-IIF] "ATIS: IIF, IPTV Interoperability Forum", 2015,
[Bakker15] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-
Peer Streaming Peer Protocol (PPSPP)", RFC 7574,
DOI 10.17487/RFC7574, July 2015,
[Castro03] Castro, M., Druschel, P., Kermarrec, A., Nandi, A., and A.
Rowstron, "SplitStream: High-Bandwidth Multicast in
Cooperative Environments", Proceedings of the 19th ACM
Symposium on Operating Systems Principles (SOSP '03),
DOI 10.1145/945445.945474, October 2003.
[Chai11] Chai, W., Wang, N., Psaras, I., Pavlou, G., Wang, C.,
de Blas, G., Ramon-Salguero, F., Liang, L., Spirou, S.,
Blefari-Melazzi, N., Beben, A., and E. Hadjioannou,
"CURLING: Content-Ubiquitous Resolution and Delivery
Infrastructure for Next Generation Services", IEEE
Communications Magazine, Volume 49, Issue 3,
DOI 10.1109/MCOM.2011.5723808, March 2011.
[Chanda13] Chanda, A., Westphal, C., and D. Raychaudhuri, "Content
Based Traffic Engineering in Software Defined Information
Centric Networks", 2013 IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS),
DOI 10.1109/INFCOMW.2013.6970717, April 2013.
[Corujo12] Corujo, D., Vidal, I., Garcia-Reinoso, J., and R. Aguiar,
"A Named Data Networking Flexible Framework for Management
Communications", IEEE Communications Magazine, Volume 50,
Issue 12, DOI 10.1109/MCOM.2012.6384449, December 2012.
Crabtree, B., Stevens, T., Allan, B., Lederer, S., Posch,
D., Mueller, C., and C. Timmerer, "Video Adaptation in
Limited/Zero Network Coverage", CCNxCon 2013, Palo Alto
Research Center (PARC), September 2013.
[Detti11] Detti, A., Blefari-Melazzi, N., Salsano, S., and M.
Pomposini, "CONET: A Content Centric Inter-Networking
Architecture", Proceedings of the ACM SIGCOMM Workshop on
DOI 10.1145/2018584.2018598, August 2011.
[Detti12] Detti, A., Pomposini, M., Blefari-Melazzi, N., Salsano,
S., and A. Bragagnini, "Offloading cellular networks with
Information-Centric Networking: the case of video
streaming", 2013 IEEE 14th International Symposium on A
World of Wireless, Mobile and Multimedia Networks
(WoWMoM), DOI 10.1109/WoWMoM.2012.6263734, June 2012.
[Detti13] Detti, A., Ricci, B., and N. Blefari-Melazzi, "Peer-To-
Peer Live Adaptive Video Streaming for Information Centric
Cellular Networks", 2013 IEEE 24th Annual International
Symposium on Personal, Indoor, and Mobile Radio
Communications (PIMRC), DOI 10.1109/PIMRC.2013.6666771,
[Fiat94] Fiat, A. and M. Naor, "Broadcast Encryption", Advances in
Cryptology - CRYPTO '93 Proceedings, Lecture Notes in
Computer Science, Volume 773, pp. 480-491, 1994.
[Fu13] Fu, B., Kunzmann, G., Wetterwald, M., Corujo, D., and R.
Costa, "QoE-aware traffic management for mobile video
delivery", 2013 IEEE International Conference on
Communications Workshops (ICC),
DOI 10.1109/ICCW.2013.6649314, June 2013.
[Grandl13] Grandl, R., Su, K., and C. Westphal, "On the Interaction
of Adaptive Video Streaming with Content-Centric
Networks", 2013 IEEE International Conference on
Multimedia and Expo (ICME), DOI 10.1109/ICME.2013.6607500,
IETF, "Peer to Peer Streaming Protocol (ppsp)",
[ISO-DASH] ISO, "Information technology -- Dynamic adaptive streaming
over HTTP (DASH) -- Part 1: Media presentation description
and segment formats", ISO/IEC 23009-1:2014, May 2014.
"ITEC - Dynamic Adaptive Streaming over HTTP", DASH
Research at the Institute of Information
Technology, Multimedia Communication Group, Alpen-Adria
Universitaet Klagenfurt, <http://dash.itec.aau.at>.
Jacobson, V., Smetters, D., Briggs, N., Plass, M.,
Stewart, P., Thornton, J., and R. Braynard, "VoCCN: Voice-
over Content-Centric Networks", Proceedings of the 2009
Workshop on Re-architecting the Internet,
DOI 10.1145/1658978.1658980, December 2009.
Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Briggs, N., and R. Braynard, "Networking Named Content",
Proceedings of the 5th International Conference on
Emerging Networking Experiments and Technologies (CoNEXT),
DOI 10.1145/1658939.1658941, December 2009.
Le Callet, P., Moeller, S., and A. Perkis, "Qualinet White
Paper on Definitions of Quality of Experience", European
Network on Quality of Experience in Multimedia Systems and
Services, COST Action IC 1003, Version 1.2, March 2013.
Lederer, S., Liu, Y., Geurts, J., Point, J., Lederer, S.,
Mueller, C., Rainer, B., Timmerer, C., and H. Hellwagner,
"Dynamic Adaptive Streaming over CCN: A Caching and
Overhead Analysis", 2013 IEEE International Conference on
Communication (ICC), DOI 10.1109/ICC.2013.6655116, June
Lederer, S., Mueller, C., Rainer, B., Timmerer, C., and H.
Hellwagner, "An Experimental Analysis of Dynamic Adaptive
Streaming over HTTP in Content Centric Networks", 2013
IEEE International Conference on Multimedia and Expo
(ICME), DOI 10.1109/ICME.2013.6607500, July 2013.
Magharei, N., Rejaie, R., and Y. Guo, "Mesh or Multiple-
Tree: A Comparative Study of Live P2P Streaming
Approaches", IEEE INFOCOM 2007 - 26th IEEE International
Conference on Computer Communications,
DOI 10.1109/INFCOM.2007.168, May 2007.
[Medard12] Medard, M., Kim, M., Parandeh-Gheibi, M., Zeng, W., and M.
Montpetit, "Quality of Experience for Multimedia
Communications: Network Coding Strategies", Laboratory of
Electronics, Massachusetts Institute of Technology, March
[MEDIEVAL] "MEDIEVAL: MultiMEDia transport for mobIlE Video
AppLications", 2010, <http://www.ict-medieval.eu>.
Montpetit, M., Holtzman, H., Chakrabarti, K., and M.
Matijasevic, "Social video consumption: Synchronized
viewing experiences across devices and networks", 2013
IEEE International Conference on Communications Workshops
(ICC), pp. 286-290, DOI 10.1109/ICCW.2013.6649245, 2013.
Montpetit, M., Westphal, C., and D. Trossen, "Network
Coding Meets Information-Centric Networking: An
Architectural Case for Information Dispersion Through
Native Network Coding", Proceedings of the 1st ACM
Workshop on Emerging Name-Oriented Mobile Networking
Design-Architecture, Algorithms, and Applications,
DOI 10.1145/2248361.2248370, June 2013.
Mueller, C., Lederer, S., and C. Timmerer, "A Proxy Effect
Analysis and Fair Adaptation Algorithm for Multiple
Competing Dynamic Adaptive Streaming over HTTP Clients",
2012 IEEE Visual Communications and Image Processing
(VCIP), DOI 10.1109/VCIP.2012.6410799, November 2012.
[NETINF] "NetInf: Network of Information", <http://www.netinf.org>.
[Posch13] Posch, D., Hellwagner, H., and P. Schartner, "On-Demand
Video Streaming based on Dynamic Adaptive Encrypted
Content Chunks", Proceedings of the 8th International
Workshop on Secure Network Protocols (NPSec '13),
DOI 10.1109/ICNP.2013.6733673, October 2013.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
[RFC7846] Cruz, R., Nunes, M., Xia, J., Huang, R., Ed., Taveira, J.,
and D. Lingli, "Peer-to-Peer Streaming Tracker Protocol
(PPSTP)", RFC 7846, DOI 10.17487/RFC7846, May 2016,
[Su14] Su, K. and C. Westphal, "On the Benefit of Information
Centric Networks for Traffic Engineering", 2014 IEEE
International Conference on Communications (ICC),
DOI 10.1109/ICC.2014.6883810, June 2014.
This work was supported in part by the European Community in the
context of the SocialSensor (FP7-ICT-287975) project and partly
performed in the Lakeside Labs research cluster at AAU. SocialSensor
receives research funding from the European Community's Seventh
Framework Programme. The work for this document was also partially
performed in the context of the FP7/NICT EU-JAPAN GreenICN project,
<http://www.greenicn.org>. Apart from this, the European Commission
has no responsibility for the content of this document. The
information in this document is provided as is and no guarantee or
warranty is given that the information is fit for any particular
purpose. The user, thereof, uses the information at its sole risk
Cedric Westphal (editor)
Alpen-Adria University Klagenfurt
Alpen-Adria University Klagenfurt
Alpen-Adria University Klagenfurt
Will (Shucheng) Liu
University of Rome Tor Vergata
Instituto de Telecomunicacoes Aveiro
City University of Hong Kong
Athlone Institute of Technology