[要約] RFC 7933は、情報中心ネットワーキング（ICN）上の適応型ビデオストリーミングに関する要約と目的を提供します。このRFCの目的は、ICN環境でのビデオストリーミングの効率と品質を向上させるためのガイドラインを提供することです。
Internet Research Task Force (IRTF) C. Westphal, Ed.
Request for Comments: 7933 Huawei
Category: Informational S. Lederer
ISSN: 2070-1721 D. Posch
C. Timmerer
Alpen-Adria University Klagenfurt
A. Azgin
W. Liu
Huawei
C. Mueller
BitMovin
A. Detti
University of Rome Tor Vergata
D. Corujo
Instituto de Telecomunicacoes Aveiro
J. Wang
City University of Hong Kong
M. Montpetit
MIT
N. Murray
Athlone Institute of Technology
August 2016
Adaptive Video Streaming over Information-Centric Networking (ICN)
情報中心型ネットワーキング（ICN）を介したアダプティブビデオストリーミング
Abstract
概要
This document considers the consequences of moving the underlying network architecture from the current Internet to an Information-Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.
このドキュメントでは、基盤となるネットワークアーキテクチャを現在のインターネットからビデオ配信の情報中心型ネットワーク（ICN）アーキテクチャに移行した場合の影響について検討します。将来のネットワークのトラフィックのほとんどはビデオであると予想されるため、既存のビデオストリーミングメカニズムを変更する方法を検討します。 ICNを介したビデオ配信に関連するいくつかの重要なトピックが表示されます。カバーされる幅広いシナリオには、以下が含まれます：ICNを介して動作し、最近のISO / IECムービングピクチャーエキスパートグループ（MPEG）標準を活用するためのHTTP（DASH）上のダイナミックアダプティブストリーミングの進化ピアツーピア（P2P）メカニズム、ピアツーピアストリーミングプロトコル（PPSP）をICNに適応、インターネットプロトコルテレビ（IPTV）によって追加された遅延制約のためにICNを介してより厳しい要件を作成し、ICNでデジタル権利を管理する。最後に、既存のメカニズムがICNによってどのように影響を受けるかを検討することに加えて、このドキュメントでは、ICN固有のビデオストリーミングメカニズムを設計するためのいくつかの調査問題を示します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、インターネットリサーチタスクフォース（IRTF）の情報中心型ネットワーキングリサーチグループのコンセンサスを表しています。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7933.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7933で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Case Scenarios for ICN and Video Streaming . . . . . . . 5
4. Video Download . . . . . . . . . . . . . . . . . . . . . . . 6
5. Video Streaming and ICN . . . . . . . . . . . . . . . . . . . 7
5.1. Introduction to Client-Driven Streaming and DASH . . . . 7
5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . . 8
5.3. Interactions of Video Streaming with ICN . . . . . . . . 8
5.3.1. Interactions of DASH with ICN . . . . . . . . . . . . 8
5.3.2. Interaction of ICN with Layered Encoding . . . . . . 10
5.4. Possible Integration of Video Streaming and ICN
Architecture . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. DASH over CCN . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Testbed, Open-Source Tools, and Dataset . . . . . . . 13
6. P2P Video Distribution and ICN . . . . . . . . . . . . . . . 14
6.1. Introduction to PPSP . . . . . . . . . . . . . . . . . . 14
6.2. PPSP over ICN: Deployment Concepts . . . . . . . . . . . 16
6.2.1. PPSP Short Background . . . . . . . . . . . . . . . . 16
6.2.2. From PPSP Messages to ICN Named-Data . . . . . . . . 16
6.2.3. Support of PPSP Interaction through a Pull-Based ICN
API . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.4. Abstract Layering for PPSP over ICN . . . . . . . . . 18
6.2.5. PPSP Interaction with the ICN Routing Plane . . . . . 19
6.2.6. ICN Deployment for PPSP . . . . . . . . . . . . . . . 19
6.3. Impact of MPEG-DASH Coding Schemes . . . . . . . . . . . 20
7. IPTV and ICN . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. IPTV Challenges . . . . . . . . . . . . . . . . . . . . . 21
7.2. ICN Benefits for IPTV Delivery . . . . . . . . . . . . . 22
8. Digital Rights Management in ICN . . . . . . . . . . . . . . 24
8.1. Broadcast Encryption for DRM in ICN . . . . . . . . . . . 24
8.2. AAA-Based DRM for ICN Networks . . . . . . . . . . . . . 27
8.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27
8.2.2. Implementation . . . . . . . . . . . . . . . . . . . 28
9. Future Steps for Video in ICN . . . . . . . . . . . . . . . . 28
9.1. Large-Scale Live Events . . . . . . . . . . . . . . . . . 29
9.2. Video Conferencing and Real-Time Communications . . . . . 29
9.3. Store-and-Forward Optimized Rate Adaptation . . . . . . 29
9.4. Heterogeneous Wireless Environment Dynamics . . . . . . 30
9.5. Network Coding for Video Distribution in ICN . . . . . . 32
9.6. Synchronization Issues for Video Distribution in ICN . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . 33
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
The unprecedented growth of video traffic has triggered a rethinking of how content is distributed, both in terms of the underlying Internet architecture and in terms of the streaming mechanisms to deliver video objects.
前例のないビデオトラフィックの増加により、基盤となるインターネットアーキテクチャと、ビデオオブジェクトを配信するためのストリーミングメカニズムの両方の観点から、コンテンツの配信方法の再考が始まりました。
In particular, the IRTF ICNRG research group has been chartered to study new architectures centered upon information; the main contributor to Internet traffic (and information dissemination) is video, and this is expected to stay the same in the near future. If ICN is expected to become prominent, it will have to support video streaming efficiently.
特に、IRTF ICNRG研究グループは、情報を中心とした新しいアーキテクチャを研究するために設立されました。インターネットトラフィック（および情報の普及）への主な貢献者はビデオであり、これは近い将来も変わらないと予想されます。 ICNが目立つようになることが予想される場合、ビデオストリーミングを効率的にサポートする必要があります。
As such, it is necessary to discuss going in two separate directions:
そのため、次の2つの方向に進むことについて話し合う必要があります。
Can the current video streaming mechanisms be leveraged and adapted to an ICN architecture?
現在のビデオストリーミングメカニズムを活用してICNアーキテクチャに適合させることはできますか？
Can (and should) new, ICN-specific video streaming mechanisms be designed to fully take advantage of the new abstractions exposed by the ICN architecture?
新しいICN固有のビデオストリーミングメカニズムを設計して、ICNアーキテクチャーによって公開された新しい抽象化を完全に活用できますか？
This document focuses on the first question in an attempt to define the use cases for video streaming and some requirements. It also focuses on a few scenarios (namely, Netflix-like video streaming, P2P video sharing, and IPTV) and identifies how the existing protocols can be adapted to an ICN architecture. In doing so, it also identifies the main issues with these protocols in this ICN context.
このドキュメントでは、ビデオストリーミングの使用例といくつかの要件を定義するために、最初の質問に焦点を当てています。また、いくつかのシナリオ（つまり、Netflixのようなビデオストリーミング、P2Pビデオ共有、IPTV）にも焦点を当て、既存のプロトコルをICNアーキテクチャにどのように適合させることができるかを示します。その際、このICNコンテキストでのこれらのプロトコルの主な問題も特定します。
In addition to this document, other works have considered specific aspects of dynamic adaptive streaming in ICN [Lederer13b] [Lederer13a] [Grandl13] [Detti12]. This document is informed by these works, as well as others.
このドキュメントに加えて、他の作品では、ICN [Lederer13b] [Lederer13a] [Grandl13] [Detti12]の動的適応ストリーミングの特定の側面を検討しています。このドキュメントは、これらの作品だけでなく他の作品からも知らされています。
In this document, we give a brief overview of the existing solutions for the selected scenarios. We then examine the interactions of such existing mechanisms with the ICN architecture and list some of the interactions any video streaming mechanism will have to consider. Finally, we identify some areas for future research.
このドキュメントでは、選択したシナリオの既存のソリューションの概要を示します。次に、そのような既存のメカニズムとICNアーキテクチャとの相互作用を調べ、ビデオストリーミングメカニズムが考慮しなければならない相互作用の一部を示します。最後に、将来の研究のためにいくつかの領域を特定します。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
例では、「C：」と「S：」はそれぞれクライアントとサーバーによって送信された行を示します。
For ICN-specific descriptions, we refer to the other research group documents [RFC7476]. For our purpose, we assume here that "ICN" refers to an architecture where content is retrieved by name and with no binding of content to a specific network location.
ICN固有の説明については、他の研究グループのドキュメント[RFC7476]を参照してください。ここでは、「ICN」がコンテンツを名前で取得し、特定のネットワークの場所にコンテンツをバインドしないアーキテクチャを指すと想定しています。
Both live and on-demand consumption of multimedia content come with timing requirements for the delivery of the content. Additionally, real-time use cases (such as audio-video conferencing [Jacobson09a], game streaming, etc.) come with stricter timing requirements. Long startup delays, buffering periods, poor video quality, etc., should be avoided to achieve a better Quality of Experience (QoE) for the consumer of the content. For a definition of QoE in the context of video distribution, please refer to [LeCallet13]. The working definition is as follows:
マルチメディアコンテンツのライブとオンデマンドの両方の消費には、コンテンツ配信のタイミング要件が伴います。さらに、リアルタイムのユースケース（オーディオビデオ会議[Jacobson09a]、ゲームストリーミングなど）には、より厳しいタイミング要件があります。コンテンツのコンシューマーのエクスペリエンスの品質（QoE）を向上させるには、起動の遅延、バッファリング期間、ビデオ品質の低下などを回避する必要があります。ビデオ配信におけるQoEの定義については、[LeCallet13]を参照してください。実際の定義は次のとおりです。
Quality of Experience (QoE) is the degree of delight or annoyance of the user of an application or service. It results from the fulfillment of his or her expectations with respect to the utility and/or enjoyment of the application or service in the light of the user's personality and current state.
Quality of Experience（QoE）は、アプリケーションまたはサービスのユーザーの喜びまたは煩わしさの程度です。これは、ユーザーの性格と現在の状態に照らして、アプリケーションまたはサービスのユーティリティおよび/または楽しみに関するユーザーの期待が満たされた結果です。
Of course, these requirements are heavily influenced by routing decisions and caching, which are central parts of ICN and that have to be considered when streaming video in such infrastructures.
もちろん、これらの要件はルーティングの決定とキャッシングによって大きく影響されます。これらはICNの中心的な部分であり、そのようなインフラストラクチャでビデオをストリーミングするときに考慮する必要があります。
Due to this range of requirements, we find it useful to narrow the focus to four scenarios (more can be included later):
この要件の範囲により、4つのシナリオに焦点を絞ることが有用であることがわかります（後でさらに含めることができます）。
o a video download architecture similar to that of Apple iTunes, where the whole file is being downloaded to the client and can be replayed there multiple times;
o Apple iTunesに似たビデオダウンロードアーキテクチャ。ファイル全体がクライアントにダウンロードされ、そこで何度も再生できます。
o a video streaming architecture for playing back movies, which is relevant for the naming and caching aspects of ICN as well as the interaction with the rate adaptation mechanism necessary to deliver the best QoE to the end user;
o ムービーを再生するためのビデオストリーミングアーキテクチャ。これは、ICNの命名とキャッシュの側面、およびエンドユーザーに最高のQoEを提供するために必要なレート適応メカニズムとの相互作用に関連しています。
o a P2P architecture for sharing videos, which introduces more stringent routing requirements in terms of locating copies of the content as the location of the peers evolves and peers join and leave the swarm they use to exchange video chunks (for P2P definitions and taxonomy, please refer to RFC 5694; and
o ビデオを共有するためのP2Pアーキテクチャ。これは、ピアの場所が進化し、ピアがビデオチャンクの交換に使用する群れに加わったり離れたりするときに、コンテンツのコピーを見つけるという点でより厳しいルーティング要件を導入します（P2P定義と分類法については、参照してください） RFC 5694、および
o IPTV, which introduces requirements for multicasting and adds stronger delay constraints.
o マルチキャストの要件を導入し、より強力な遅延制約を追加するIPTV。
Other scenarios, such as video conferencing and real-time video communications, are not explicitly discussed in this document even though they are in scope. Also, events of mass-media distribution, such as a large crowd at a live event, add new requirements to be included in later versions.
ビデオ会議やリアルタイムビデオ通信などの他のシナリオは、範囲内であっても、このドキュメントでは明示的に説明されていません。また、ライブイベントでの大勢の群衆など、マスメディア配信のイベントでは、新しい要件が追加され、以降のバージョンに含まれるようになります。
The current state-of-the-art protocols in an IP context can be modified for the ICN architecture. The remainder of this document is organized as follows: Section 4 discusses video download; Section 5 briefly describes DASH [ISO-DASH] and Layered Encoding (Modification Detection Code (MDC), Scalable Video Coding (SVC)); Section 6 focuses on P2P and PPSP; Section 7 highlights the requirements of IPTV; Section 8 describes the issues of DRM; and Section 9 lists some research issues to be solved for ICN-specific video delivery mechanisms.
IPコンテキスト内の最新のプロトコルは、ICNアーキテクチャ用に変更できます。このドキュメントの残りの部分は、次のように構成されています。セクション4では、ビデオのダウンロードについて説明します。セクション5では、DASH [ISO-DASH]およびレイヤードエンコーディング（変更検出コード（MDC）、スケーラブルビデオコーディング（SVC））について簡単に説明します。セクション6はP2PとPPSPに焦点を当てています。セクション7はIPTVの要件を強調しています。セクション8では、DRMの問題について説明します。セクション9には、ICN固有のビデオ配信メカニズムで解決すべきいくつかの調査問題がリストされています。
Video-conferencing and real-time-video communications will be described in further detail in future works. Mass distribution of content at live, large-scale events (stadiums, concert halls, etc.) for which there is no clearly adopted existing protocol is another topic for further research.
ビデオ会議およびリアルタイムビデオ通信については、今後の作業でさらに詳しく説明します。既存のプロトコルが明確に採用されていないライブの大規模なイベント（スタジアム、コンサートホールなど）でのコンテンツの大量配布は、今後の研究のもう1つのトピックです。
Video download, namely the fetching of a video file from a server or a cache down to the user's local storage, is a natural application of ICN. It should be supported natively without requiring any specific considerations.
ビデオのダウンロード、つまりサーバーまたはキャッシュからユーザーのローカルストレージへのビデオファイルのフェッチは、ICNの自然なアプリケーションです。特定の考慮事項を必要とせずに、ネイティブでサポートされる必要があります。
This is supported now by a host of protocols (say, Secure Copy (SCP), FTP, or over HTTP), which would need to be replaced by new ICN-specific protocols to retrieve content in ICNs.
これは、多数のプロトコル（Secure Copy（SCP）、FTP、またはHTTPなど）でサポートされるようになりました。ICNのコンテンツを取得するには、新しいICN固有のプロトコルに置き換える必要があります。
However, current mechanisms are built atop existing transport protocols. Some ICN proposals (Context-Centric Network (CCN) or Named Data Networking (NDN), for instance) attempt to leverage the work done upon these transport protocols. One proposal is to use the TCP congestion window (and the associated Adaptive Increase, Multiplicative Decrease (AIMD)) to decide how many object requests ("Interests" in CCN/NDN terminology) should be in flight at any point in time.
ただし、現在のメカニズムは既存のトランスポートプロトコルの上に構築されています。一部のICN提案（コンテキスト中心ネットワーク（CCN）または名前付きデータネットワーク（NDN）など）は、これらのトランスポートプロトコルで行われた作業を活用しようとします。 1つの提案は、TCP輻輳ウィンドウ（および関連する適応増加、乗法減少（AIMD））を使用して、任意の時点で実行中のオブジェクト要求（CCN / NDN用語の「対象」）の数を決定することです。
It should be noted that ICN intrinsically supports different transport mechanisms, which could achieve better performance than TCP, as they subsume TCP into a special case. For instance, one could imagine a link-by-link transport coupled with caching. This is enabled by the ICN architecture and would facilitate the point-to-point download of video files.
ICNは本質的に異なるトランスポートメカニズムをサポートしていることに注意してください。これらはTCPを特殊なケースに組み込んでいるため、TCPよりも優れたパフォーマンスを実現できます。たとえば、キャッシュとリンクされたリンクごとのトランスポートを想像できます。これはICNアーキテクチャによって実現され、ビデオファイルのポイントツーポイントダウンロードを容易にします。
Media streaming over HTTP and, in a further consequence, streaming over the TCP, has become omnipresent in today's Internet. Content providers such as Netflix, Hulu, and Vudu do not deploy their own streaming equipment: they use the existing Internet infrastructure as it is and simply deploy their own services Over The Top (OTT). This streaming approach works surprisingly well without any particular support from the underlying network due to the use of efficient video compression, Content Delivery Networks (CDNs), and adaptive video players. Earlier video streaming research mostly recommended use of the User Datagram Protocol (UDP) combined with the Real-time Transport Protocol (RTP). It assumed it would not be possible to transfer multimedia data smoothly with TCP, because of its throughput variations and large retransmission delays. This point of view has significantly evolved today. HTTP streaming, and especially its most simple form known as progressive download, has become very popular over the past few years because it has some major benefits compared to RTP streaming. As a consequence of the consistent use of HTTP for this streaming method, the existing Internet infrastructure consisting of proxies, caches, and CDNs could be used. Originally, this architecture was designed to support best-effort delivery of files and not real-time transport of multimedia data. Nevertheless, real-time streaming based on HTTP could also take advantage of this architecture, in comparison to RTP, which could not leverage any of the aforementioned components. Another benefit that results from the use of HTTP is that the media stream could easily pass firewalls or Network Address Translation (NAT) gateways, which was definitely a key for the success of HTTP streaming. However, HTTP streaming is not the holy grail of streaming as it also introduces some drawbacks compared to RTP. Nevertheless, in an ICN-based video streaming architecture these aspects also have to be considered.
HTTPを介したメディアストリーミング、さらにはTCPを介したストリーミングは、今日のインターネットで広く普及しています。 Netflix、Hulu、Vuduなどのコンテンツプロバイダーは、独自のストリーミング機器を展開しません。既存のインターネットインフラストラクチャをそのまま使用し、独自のサービスOver The Top（OTT）を展開するだけです。このストリーミングアプローチは、効率的なビデオ圧縮、コンテンツ配信ネットワーク（CDN）、およびアダプティブビデオプレーヤーを使用しているため、基盤となるネットワークからの特別なサポートがなくても驚くほどうまく機能します。以前のビデオストリーミングの研究では、ユーザーデータグラムプロトコル（UDP）とリアルタイム転送プロトコル（RTP）の併用が主に推奨されていました。スループットの変動と大きな再送信遅延のため、TCPではマルチメディアデータをスムーズに転送できないと想定していました。この視点は、今日、大きく進化しました。 HTTPストリーミング、特にプログレッシブダウンロードと呼ばれる最も単純な形式は、RTPストリーミングと比較していくつかの主要な利点があるため、過去数年間で非常に人気があります。このストリーミング方式でHTTPを一貫して使用した結果、プロキシ、キャッシュ、およびCDNで構成される既存のインターネットインフラストラクチャを使用できます。もともとこのアーキテクチャは、マルチメディアデータのリアルタイム転送ではなく、ファイルのベストエフォート配信をサポートするように設計されていました。それにもかかわらず、HTTPに基づくリアルタイムストリーミングも、前述のコンポーネントを利用できないRTPと比較して、このアーキテクチャを利用できます。 HTTPの使用によるもう1つの利点は、メディアストリームがファイアウォールまたはネットワークアドレス変換（NAT）ゲートウェイを簡単に通過できることです。これは、HTTPストリーミングの成功の鍵でした。ただし、HTTPストリーミングは、RTPと比較していくつかの欠点があるため、ストリーミングの聖杯ではありません。それにもかかわらず、ICNベースのビデオストリーミングアーキテクチャでは、これらの側面も考慮する必要があります。
The basic concept of DASH [ISO-DASH] is to use segments of media content, which can be encoded at different resolutions, bit rates, etc., as so-called representations. These segments are served by conventional HTTP web servers and can be addressed via HTTP GET requests from the client. As a consequence, the streaming system is pull-based and the entire streaming logic is located on the client, which makes it scalable and allows for adaptation of the media stream to the client's capabilities.
DASH [ISO-DASH]の基本概念は、いわゆる表現として、さまざまな解像度、ビットレートなどでエンコードできるメディアコンテンツのセグメントを使用することです。これらのセグメントは、従来のHTTP Webサーバーによって提供され、クライアントからのHTTP GET要求を介してアドレス指定できます。その結果、ストリーミングシステムはプルベースであり、ストリーミングロジック全体がクライアント上に配置されるため、スケーラブルになり、メディアストリームをクライアントの機能に適合させることができます。
In addition to this, the content can be distributed using conventional CDNs and their HTTP infrastructure, which also scales very well. In order to specify the relationship between the contents' media segments and the associated bit rate, resolution, and timeline, the Media Presentation Description (MPD) is used, which is an XML document. The MPD refers to the available media segments using HTTP URLs, which can be used by the client for retrieving them.
これに加えて、コンテンツは従来のCDNとそれらのHTTPインフラストラクチャを使用して配布することができ、これも非常によく拡張されます。コンテンツのメディアセグメントと関連するビットレート、解像度、およびタイムラインの関係を指定するために、XML文書であるMedia Presentation Description（MPD）が使用されます。 MPDは、HTTP URLを使用して使用可能なメディアセグメントを参照します。これは、クライアントがそれらを取得するために使用できます。
Another approach for video streaming consists in using layered encoding. Namely, scalable video coding formats the video stream into different layers: a base layer that can be decoded to provide the lowest bit rate for the specific stream and enhancement layers that can be transmitted separately if network conditions allow. The higher layers offer higher resolutions and enhancement of the video quality, while the layered approach allows for adaptation to the network conditions. This is used in an MPEG-4 scalable profile or H.263+. H264SVC is available but not much deployed. JPEG2000 has a wavelet transform approach for layered encoding but has not been deployed much either. It is not clear if the layered approach is fine-grained enough for rate control.
ビデオストリーミングのもう1つのアプローチは、階層化エンコーディングを使用することです。つまり、スケーラブルビデオコーディングは、ビデオストリームをさまざまなレイヤーにフォーマットします。特定のストリームに最低ビットレートを提供するためにデコードできるベースレイヤーと、ネットワーク条件が許す場合は個別に送信できる拡張レイヤーです。上位層はより高い解像度とビデオ品質の向上を提供し、階層化アプローチはネットワーク条件への適応を可能にします。これは、MPEG-4スケーラブルプロファイルまたはH.263 +で使用されます。 H264SVCは利用可能ですが、あまり展開されていません。 JPEG2000には、レイヤードエンコーディング用のウェーブレット変換アプローチがありますが、あまり配備されていません。階層化アプローチがレート制御のために十分にきめ細かいのかどうかは明確ではありません。
Video streaming (DASH in particular) has been designed with a goal that is aligned with that of most ICN proposals: it is a client-based mechanism that requests items (in this case, chunks of a video stream) by name.
ビデオストリーミング（特にDASH）は、ほとんどのICN提案の目標に合わせた目標で設計されています。これは、名前でアイテム（この場合は、ビデオストリームのチャンク）を要求するクライアントベースのメカニズムです。
ICN and MPEG-DASH [ISO-DASH] have several elements in common:
ICNとMPEG-DASH [ISO-DASH]には、いくつかの共通の要素があります。
o the client-initiated pull approach;
o クライアントが開始するプルアプローチ。
o the content being dealt with in pieces (or chunks);
o 断片（またはチャンク）で処理されるコンテンツ。
o the support of efficient replication and distribution of content pieces within the network;
o ネットワーク内のコンテンツの効率的な複製と配信のサポート。
o the scalable, session-free nature of the exchange between the client and the server at the streaming layer: the client is free to request any chunk from any location; and
o ストリーミング層でのクライアントとサーバー間の交換のスケーラブルでセッションフリーの性質：クライアントは任意の場所から任意のチャンクを自由に要求できます。そして
o the support for potentially multiple source locations.
o 潜在的に複数のソースの場所のサポート。
For the last point, DASH may list multiple source URLs in a manifest, and ICN is agnostic to the location of a copy it is receiving. We do not imply that current video streaming mechanisms attempt to draw the content from multiple sources concurrently. This is a potential benefit of ICN but is not considered in the current approaches mentioned in this document.
最後の点として、DASHはマニフェストに複数のソースURLをリストする場合があり、ICNは受信するコピーの場所に依存しません。現在のビデオストリーミングメカニズムが複数のソースから同時にコンテンツを描画しようとしていることを意味するものではありません。これはICNの潜在的な利点ですが、このドキュメントで言及されている現在のアプローチでは考慮されていません。
As ICN is a promising candidate for the Future Internet (FI) architecture, it is useful to investigate its suitability in combination with multimedia streaming standards like MPEG-DASH. In this context, the purpose of this section is to present the usage of ICN instead of HTTP in MPEG-DASH.
ICNはフューチャーインターネット（FI）アーキテクチャの有望な候補であるため、MPEG-DASHなどのマルチメディアストリーミング標準と組み合わせてその適合性を調査することは有用です。このコンテキストでは、このセクションの目的は、MPEG-DASHでのHTTPではなくICNの使用法を示すことです。
However, there are some issues that arise from using a dynamic rate adaptation mechanism in an ICN architecture (note that some of the issues are related to caching and are not necessarily unique to ICN):
ただし、ICNアーキテクチャで動的レート適応メカニズムを使用することから生じるいくつかの問題があります（一部の問題はキャッシングに関連しており、必ずしもICNに固有のものではないことに注意してください）。
o Naming of the data in DASH does not necessarily follow the ICN convention of any of the ICN proposals. Several chunks of the same video stream might currently go by different names that, for instance, do not share a common prefix. There is a need to harmonize the naming of the chunks in DASH with the naming conventions of the ICN. The naming convention of using a filename/time/encoding format could, for instance, be made compatible with the convention of CCN.
o DASHでのデータの命名は、必ずしもICN提案のいずれかのICN規則に従っているわけではありません。同じビデオストリームのいくつかのチャンクは、現在、たとえば共通のプレフィックスを共有しない異なる名前で移動する場合があります。 DASHのチャンクの命名をICNの命名規則と調和させる必要があります。たとえば、ファイル名/時間/エンコーディング形式を使用する命名規則は、CCNの規則と互換性を持たせることができます。
o While chunks can be retrieved from any server, the rate adaptation mechanism attempts to estimate the available network bandwidth so as to select the proper playback rate and keep its playback buffer at the proper level. Therefore, there is a need to either include some location semantics in the data chunks so as to properly assess the throughput to a specific location or to design a different mechanism to evaluate the available network bandwidth.
o チャンクは任意のサーバーから取得できますが、レート適応メカニズムは、適切な再生レートを選択し、その再生バッファーを適切なレベルに保つために、利用可能なネットワーク帯域幅を推定しようとします。したがって、特定の場所へのスループットを適切に評価するため、または使用可能なネットワーク帯域幅を評価するための別のメカニズムを設計するために、データチャンクに場所のセマンティクスを含める必要があります。
o The typical issue of access control and accounting happens in this context, where chunks can be cached in the network outside of the administrative control of the content publisher. It might be a requirement from the owner of the video stream that access to these data chunks needs to be accounted/billed/monitored.
o アクセス制御とアカウンティングの一般的な問題は、このような状況で発生します。この場合、コンテンツパブリッシャーの管理制御外のネットワークにチャンクをキャッシュできます。ビデオストリームの所有者は、これらのデータチャンクへのアクセスを計算、課金、監視する必要がある場合があります。
o Dynamic streaming multiplies the representations of a given video stream, therefore diminishing the effectiveness of caching: namely, to get a hit for a chunk in the cache, it has to be for the same format and encoding values. Alternatively, to get the same hit rate as a stream using a single encoding, the cache size must be scaled up to include all the possible representations.
o ダイナミックストリーミングは、特定のビデオストリームの表現を乗算するため、キャッシングの効率が低下します。つまり、キャッシュ内のチャンクにヒットするためには、同じフォーマットとエンコーディング値でなければなりません。または、単一のエンコーディングを使用してストリームと同じヒット率を得るには、可能なすべての表現を含めるようにキャッシュサイズを拡大する必要があります。
o Caching introduces oscillatory dynamics as it may modify the estimation of the available bandwidth between the end user and the repository from which it is getting the chunks. For instance, if an edge cache holds a low resolution representation near the user, the user getting these low resolution chunks will observe a good performance and will then request higher resolution chunks. If those are hosted on a server with poor performance, then the client would have to switch back to the low representation. This oscillation may be detrimental to the perceived QoE of the user.
oキャッシュは、エンドユーザーとチャンクの取得元であるリポジトリとの間の使用可能な帯域幅の見積もりを変更する可能性があるため、振動ダイナミクスを導入します。たとえば、エッジキャッシュがユーザーの近くで低解像度の表現を保持している場合、これらの低解像度のチャンクを取得するユーザーは良好なパフォーマンスを観察し、より高い解像度のチャンクを要求します。それらがパフォーマンスの低いサーバーでホストされている場合、クライアントは低表示に戻す必要があります。この振動は、ユーザーの知覚されるQoEに有害な場合があります。
o The ICN transport mechanism needs to be compatible to some extent with DASH. To take a CCN example, the rate at which interests are issued should be such that the chunks received in return arrive fast enough and with the proper encoding to keep the playback buffer above some threshold.
o ICNトランスポートメカニズムは、ある程度DASHと互換性がある必要があります。 CCNの例をとるには、インタレストが発行されるレートは、返される受信チャンクが十分に速く、適切なエンコーディングで再生バッファーがしきい値を超えるように保つようなものでなければなりません。
o The usage of multiple network interfaces is possible in ICN, enabling a seamless handover between them. For the combination with DASH, an intelligent strategy that should focus on traffic load-balancing between the available links may be necessary. This would increase the effective media throughput of DASH by leveraging the combined available bandwidth of all links; however, it could potentially lead to high variations of the media throughput.
o ICNでは複数のネットワークインターフェイスの使用が可能で、それらの間のシームレスなハンドオーバーが可能です。 DASHとの組み合わせでは、利用可能なリンク間のトラフィックロードバランシングに焦点を当てたインテリジェントな戦略が必要になる場合があります。これにより、すべてのリンクの利用可能な合計帯域幅を活用して、DASHの有効なメディアスループットが向上します。ただし、メディアスループットの変動が大きくなる可能性があります。
o DASH does not define how the MPD is retrieved; hence, this is compatible with CCN. However, the current profiles defined within MPEG-DASH require the MPD to contain HTTP URLs (including HTTP and HTTPS URI schemes) to identify segments. To enable a more integrated approach as described in this document, an additional profile for DASH over CCN has to be defined, enabling ICN/CCN-based URIs to identify and request the media segments.
o DASHはMPDの取得方法を定義しません。したがって、これはCCNと互換性があります。ただし、MPEG-DASH内で定義されている現在のプロファイルでは、セグメントを識別するために、MPDにHTTP URL（HTTPおよびHTTPS URIスキームを含む）を含める必要があります。このドキュメントで説明されているように、より統合されたアプローチを有効にするには、DASH over CCNの追加プロファイルを定義して、ICN / CCNベースのURIがメディアセグメントを識別および要求できるようにする必要があります。
We describe in Section 5.4 a potential implementation of a dynamic adaptive video stream over ICN, based upon DASH and CCN [Jacobson09b].
セクション5.4で、DASHとCCN [Jacobson09b]に基づく、ICNを介した動的適応ビデオストリームの実装の可能性について説明します。
Issues of interest to an ICN architecture in the context of layered video streaming include:
レイヤードビデオストリーミングのコンテキストでICNアーキテクチャに関係する問題は次のとおりです。
o Caching of the multiple layers. The caching priority should go to the base layer and to defining caching policy in order to decide when to cache enhancement layers;
o 複数のレイヤーのキャッシュ。キャッシング優先度は、ベースレイヤーに移動し、キャッシングポリシーを定義して、拡張レイヤーをキャッシュするタイミングを決定する必要があります。
o Synchronization of multiple content streams, as the multiple layers may come from different sources in the network (for instance, the base layer might be cached locally while the enhancement layers may be stored in the origin server). Video and audio-video streams must be synchronized, and this includes both intra-layer synchronization (for the layers of the same video or audio stream) and inter-stream synchronization (see Section 9 for other synchronization aspects to be included in the "Future Steps for Video in ICN"); and
o複数のコンテンツストリームの同期化。これは、複数のレイヤーがネットワークの異なるソースから取得される場合があるためです（たとえば、基本レイヤーはローカルにキャッシュされ、拡張レイヤーはオリジンサーバーに格納される場合があります）。ビデオストリームとオーディオビデオストリームは同期する必要があります。これには、レイヤー内同期（同じビデオストリームまたはオーディオストリームのレイヤーの場合）とストリーム間同期の両方が含まれます（「Future ICNでのビデオの手順 "）;そして
o Naming of the different layers: when the client requests an object, the request can be satisfied with the base layer alone, aggregated with enhancement layers. Should one request be sufficient to provide different streams? In a CCN architecture, for instance, this would violate a "one Interest, one Data packet" principle and the client would need to specify each layer it would like to receive. In a Pub/Sub architecture, the Rendezvous Point would have to make a decision as to which layers (or which pointer to which layer's location) to return.
o さまざまなレイヤーの名前付け：クライアントがオブジェクトを要求するとき、要求は基本レイヤーだけで満たされ、拡張レイヤーで集約されます。異なるストリームを提供するには、1つのリクエストで十分ですか？たとえば、CCNアーキテクチャでは、これは「1インタレスト、1データパケット」の原則に違反し、クライアントは受信する各層を指定する必要があります。 Pub / Subアーキテクチャでは、ランデブーポイントはどのレイヤー（またはどのレイヤーの場所へのどのポインター）を返すかを決定する必要があります。
DASH is intended to enable adaptive streaming, i.e., each content piece can be provided in different qualities, formats, languages, etc., to cope with the diversity of today's networks and devices. As this is an important requirement for Future Internet proposals like CCN, the combination of those two technologies seems to be obvious. Since those two proposals are located at different protocol layers -- DASH at the application and CCN at the network layer -- they can be combined very efficiently to leverage the advantages of both and potentially eliminate existing disadvantages. As CCN is not based on classical host-to-host connections, it is possible to consume content from different origin nodes as well as over different network links in parallel, which can be seen as an intrinsic error resilience feature with respect to the network. This is a useful feature of CCN for adaptive multimedia streaming within mobile environments since most mobile devices are equipped with multiple network links like 3G and Wi-Fi. CCN offers this functionality out of the box, which is beneficial when used for DASH-based services. In particular, it is possible to enable adaptive video streaming handling both bandwidth and network link changes. That is, CCN handles the network link decision and DASH is implemented on top of CCN to adapt the video stream to the available bandwidth.
DASHは、アダプティブストリーミングを可能にすることを目的としています。つまり、各コンテンツをさまざまな品質、フォーマット、言語などで提供して、今日のネットワークやデバイスの多様性に対応できます。これはCCNのような将来のインターネットの提案にとって重要な要件であるため、これらの2つのテクノロジーの組み合わせは明白なようです。これら2つの提案は異なるプロトコルレイヤー（アプリケーションのDASHとネットワークレイヤーのCCN）にあるため、非常に効率的に組み合わせて両方の利点を活用し、既存の欠点を排除することができます。 CCNは従来のホスト対ホスト接続に基づいていないため、さまざまな起点ノードからコンテンツを消費することも、さまざまなネットワークリンクを介してコンテンツを並行して消費することも可能です。これは、ネットワークに関する本質的なエラー回復機能と見なすことができます。ほとんどのモバイルデバイスには3GやWi-Fiなどの複数のネットワークリンクが装備されているため、これはモバイル環境内でのアダプティブマルチメディアストリーミングのためのCCNの便利な機能です。 CCNはこの機能をそのまま使用できるため、DASHベースのサービスに使用すると便利です。特に、帯域幅とネットワークリンクの両方の変更を処理するアダプティブビデオストリーミングを有効にすることができます。つまり、CCNはネットワークリンクの決定を処理し、DASHはCCNの上に実装されて、ビデオストリームを使用可能な帯域幅に適合させます。
In principle, there are two options to integrate DASH and CCN: a proxy service acting as a broker between HTTP and CCN as proposed in [Detti12], and the DASH client implementing a native CCN interface. The former transforms an HTTP request to a corresponding Interest packet as well as a Data packet back to an HTTP response, including reliable transport as offered by TCP. This may be a good compromise to implement CCN in a managed network and to support legacy devices. Since such a proxy is already described in [Detti12], this document
原則として、DASHとCCNを統合するには、[Detti12]で提案されているようにHTTPとCCN間のブローカーとして機能するプロキシサービスと、ネイティブCCNインターフェースを実装するDASHクライアントの2つのオプションがあります。前者は、HTTPリクエストを対応するInterestパケットに変換し、TCPが提供する信頼性の高いトランスポートを含むデータパケットをHTTP応答に変換します。これは、管理対象ネットワークにCCNを実装し、レガシーデバイスをサポートするための適切な妥協案になる可能性があります。そのようなプロキシはすでに[Detti12]で説明されているので、このドキュメントは
focuses on a more integrated approach, aiming at fully exploiting the potential of a CCN DASH client. That is, we describe a native CCN interface within the DASH client, which adopts a CCN naming scheme (CCN URIs) to denote segments in the MPD. In this architecture, only the network access component on the client has to be modified and the segment URIs within MPD have to be updated according to the CCN naming scheme.
CCN DASHクライアントの可能性を十分に活用することを目的とした、より統合されたアプローチに焦点を当てています。つまり、DASHクライアント内のネイティブCCNインターフェイスについて説明します。これは、CCN命名スキーム（CCN URI）を採用してMPDのセグメントを示します。このアーキテクチャでは、クライアント上のネットワークアクセスコンポーネントのみを変更する必要があり、MPD内のセグメントURIをCCN命名スキームに従って更新する必要があります。
Initially, the DASH client retrieves the MPD containing the CCN URIs of the content representations including the media segments. The naming scheme of the segments may reflect intrinsic features of CCN like versioning and segmentation support. Such segmentation support is already compulsory for multimedia streaming in CCN; thus, it can also be leveraged for DASH-based streaming over CCN. The CCN versioning can be adopted in a further step to signal different representations of the DASH-based content, which enables an implicit adaptation of the requested content to the clients' bandwidth conditions. That is, the Interest packet already provides the desired characteristics of a segment (such as bit rate, resolution, etc.) within the content name (or potentially within parameters defined as extra types in the packet formats). Additionally, if bandwidth conditions of the corresponding interfaces or routing paths allow so, DASH media segments could be aggregated automatically by the CCN nodes, which reduces the amount of Interest packets needed to request the content. However, such approaches need further research, specifically in terms of additional intelligence and processing power needed at the CCN nodes.
最初に、DASHクライアントは、メディアセグメントを含むコンテンツ表現のCCN URIを含むMPDを取得します。セグメントの命名体系は、バージョン管理やセグメンテーションサポートなどのCCNの固有の機能を反映している場合があります。このようなセグメンテーションサポートは、CCNのマルチメディアストリーミングではすでに必須です。したがって、CCNを介したDASHベースのストリーミングにも利用できます。 CCNバージョン管理は、DASHベースのコンテンツのさまざまな表現を通知するために、次のステップで採用できます。これにより、要求されたコンテンツをクライアントの帯域幅条件に暗黙的に適合させることができます。つまり、インタレストパケットは、コンテンツ名内（またはパケット形式で追加の型として定義されたパラメータ内）のセグメント（ビットレート、解像度など）の望ましい特性をすでに提供しています。さらに、対応するインターフェイスまたはルーティングパスの帯域幅条件が許す場合、DASHメディアセグメントはCCNノードによって自動的に集約され、コンテンツを要求するために必要なインタレストパケットの量を減らします。ただし、そのようなアプローチでは、特にCCNノードで必要な追加のインテリジェンスと処理能力の観点から、さらに調査が必要です。
After requesting the MPD, the DASH client will start to request particular segments. Therefore, CCN Interest packets are generated by the CCN access component and forwarded to the available interfaces. Within the CCN, these Interest packets leverage the efficient interest aggregation for, e.g., popular content, as well as the implicit multicast support. Finally, the Interest packets are satisfied by the corresponding Data packets containing the video segment data, which are stored on the origin server or any CCN node, respectively. With an increasing popularity of the content, it will be distributed across the network resulting in lower transmission delays and reduced bandwidth requirements for origin servers and content providers, respectively.
MPDを要求した後、DASHクライアントは特定のセグメントの要求を開始します。したがって、CCNインタレストパケットは、CCNアクセスコンポーネントによって生成され、使用可能なインターフェイスに転送されます。 CCN内では、これらのInterestパケットは、人気のあるコンテンツなどの効率的なInterest集約と暗黙的なマルチキャストサポートを活用します。最後に、インタレストパケットは、ビデオセグメントデータを含む対応するデータパケットによって満たされます。これらのデータパケットは、それぞれ起点サーバーまたは任意のCCNノードに格納されます。コンテンツの人気が高まるにつれ、コンテンツはネットワーク全体に配信され、その結果、送信遅延が減少し、オリジンサーバーとコンテンツプロバイダーの帯域幅要件がそれぞれ減少します。
With the extensive usage of in-network caching, new drawbacks are introduced since the streaming logic is located at the client, i.e., clients are not aware of each other and the network infrastructure and cache states. Furthermore, negative effects are introduced when multiple clients compete in a bottleneck and when caching influences this bandwidth competition. As mentioned above, the clients request individual portions of the content based on available bandwidth, which is calculated using throughput estimations. This uncontrolled distribution of the content influences the adaptation process of adaptive streaming clients. The impact of this falsified throughput estimation could be tremendous and leads to a wrong adaptation decision that may impact the QoE at the client, as shown in [Mueller12]. In ICN, the client does not have the knowledge from which source the requested content is actually served or how many origin servers of the content are available, as this is transparent and depends on the name-based routing. This introduces the challenge that the adaptation logic of the adaptive streaming client is not aware of the event when the ICN routing decides to switch to a different origin server or content is coming through a different link/interface. As most algorithms implementing the adaption logic use bandwidth measurements and related heuristics, the adaptation decisions are no longer valid when changing origin servers (or links), and these decisions potentially cause playback interruptions and, consequently, stalling. Additionally, ICN supports the usage of multiple interfaces. A seamless handover between these interfaces (and different sources for the content) comes together with changes in performance, e.g., due to switching between fixed and wireless, 3G/4G and Wi-Fi networks, different types of servers (say with/ without Shared Secret Data (SSD) or hardware acceleration), etc.
ネットワーク内のキャッシュを広範囲に使用すると、ストリーミングロジックがクライアントに配置されるため、新しい欠点が生じます。つまり、クライアントはお互いを認識しておらず、ネットワークインフラストラクチャとキャッシュの状態を認識していません。さらに、複数のクライアントがボトルネックで競合し、キャッシングがこの帯域幅の競合に影響を与える場合、悪影響が生じます。上記のように、クライアントは、スループットの見積もりを使用して計算される使用可能な帯域幅に基づいて、コンテンツの個々の部分を要求します。このコンテンツの制御されていない配布は、アダプティブストリーミングクライアントのアダプテーションプロセスに影響を与えます。 [Mueller12]に示されているように、この誤ったスループット推定の影響は非常に大きく、クライアントでのQoEに影響を与える可能性がある誤った適応決定につながる可能性があります。 ICNでは、クライアントは、要求されたコンテンツが実際に提供されるソースや、コンテンツの使用可能なオリジンサーバーの数を認識していません。これは透過的であり、名前ベースのルーティングに依存するためです。これは、ICNルーティングが別のオリジンサーバーに切り替えることを決定した場合、またはコンテンツが別のリンク/インターフェイスを介して送信される場合、アダプティブストリーミングクライアントのアダプテーションロジックがイベントを認識しないという課題をもたらします。適応ロジックを実装するほとんどのアルゴリズムは帯域幅測定と関連するヒューリスティックを使用するため、元のサーバー（またはリンク）を変更すると、適応の決定は無効になり、これらの決定は再生の中断を引き起こし、その結果、停止する可能性があります。さらに、ICNは複数のインターフェースの使用をサポートします。これらのインターフェース（およびコンテンツのさまざまなソース）間のシームレスなハンドオーバーは、たとえば固定ネットワークとワイヤレスネットワーク、3G / 4GネットワークとWi-Fiネットワーク、さまざまなタイプのサーバー（共有あり/なしの切り替えなど）によるパフォーマンスの変化を伴います。秘密データ（SSD）またはハードウェアアクセラレーション）など
Considering these characteristics of ICN, adaptation algorithms merely based on bandwidth measurements are not appropriate anymore, as potentially each segment can be transferred from another ICN node or interface, all with different bandwidth conditions. Thus, adaptation algorithms taking into account these intrinsic characteristics of ICN are preferred over algorithms based on mere bandwidth measurements.
ICNのこれらの特性を考慮すると、すべての帯域幅条件が異なる別のICNノードまたはインターフェイスから各セグメントを転送できる可能性があるため、帯域幅測定に基づく適応アルゴリズムはもはや適切ではありません。したがって、ICNのこれらの固有の特性を考慮した適応アルゴリズムは、単なる帯域幅測定に基づくアルゴリズムよりも優先されます。
For the evaluations of DASH over CCN, a testbed with open-source tools and datasets is provided in [ITEC-DASH]. In particular, it provides two client-player implementations, (i) a libdash extension for DASH over CCN and (ii) a VLC plugin implementing DASH over CCN. For both implementations, the CCNx implementation has been used as a basis.
CCNを介したDASHの評価のために、オープンソースのツールとデータセットを備えたテストベッドが[ITEC-DASH]で提供されています。特に、2つのクライアントプレーヤー実装を提供します。（i）CCNを介したDASHのlibdash拡張機能と（ii）CCNを介したDASHを実装するVLCプラグイン。どちらの実装でも、CCNx実装が基礎として使用されています。
The general architecture of libdash is organized in modules so that the library implements a MPD parser and an extensible connection manager. The library provides object-oriented interfaces for these modules to access the MPD and the downloadable segments. These components are extended to support DASH over CCN and are located in a separate development branch of the GitHub project available at <http://www.github.com/bitmovin/libdash>. libdash comes together with a fully featured DASH player with a QT-based front end, demonstrating the usage of libdash and providing a scientific evaluation platform. As an alternative, patches for the DASH plugin of the VLC player are provided. These patches can be applied to the latest source code checkout of VLC resulting in a DASH-over-CCN-enabled VLC player.
libdashの一般的なアーキテクチャーは、ライブラリーがMPDパーサーと拡張可能な接続マネージャーを実装するように、モジュールに編成されています。ライブラリは、これらのモジュールがMPDおよびダウンロード可能なセグメントにアクセスするためのオブジェクト指向のインターフェイスを提供します。これらのコンポーネントは、CCN上のDASHをサポートするように拡張されており、<http://www.github.com/bitmovin/libdash>で入手可能なGitHubプロジェクトの別の開発ブランチにあります。 libdashは、QTベースのフロントエンドを備えたフル機能のDASHプレーヤーと一緒に提供され、libdashの使用方法を示し、科学的評価プラットフォームを提供します。別の方法として、VLCプレーヤーのDASHプラグインのパッチが提供されています。これらのパッチは、VLCの最新のソースコードチェックアウトに適用でき、DASH-over-CCN対応のVLCプレーヤーになります。
Finally, a DASH-over-CCN dataset is provided in the form of a CCNx repository. It includes 15 different quality representation of the well-known Big Buck Bunny Movie, ranging from 100 kbps to 4500 kbps. The content is split into segments of two seconds and is described by an associated MPD using the presented naming scheme in Section 5.1. This repository can be downloaded from [ITEC-DASH] and is also provided by a publicly accessible CCNx node. Associated routing commands for the CCNx namespaces of the content are provided via scripts coming together with the dataset and can be used as a public testbed.
最後に、DASH-over-CCNデータセットがCCNxリポジトリの形式で提供されます。これには、有名なビッグバックバニームービーの15種類の品質表現が含まれています（100 kbpsから4500 kbpsまで）。コンテンツは2秒のセグメントに分割され、セクション5.1で提示された命名スキームを使用して、関連するMPDによって記述されます。このリポジトリは[ITEC-DASH]からダウンロードでき、公的にアクセス可能なCCNxノードによっても提供されます。コンテンツのCCNx名前空間に関連するルーティングコマンドは、データセットに付属するスクリプトを介して提供され、パブリックテストベッドとして使用できます。
Peer-to-Peer distribution is another form of distributing content -- and video in particular -- that ICNs need to support. We see now how an existing protocol such as PPSP can be modified to work in an ICN environment.
ピアツーピア配信は、ICNがサポートする必要のあるコンテンツ（特にビデオ）を配信するもう1つの形式です。ここで、PPSPなどの既存のプロトコルをICN環境で動作するように変更する方法を説明します。
P2P Video Streaming (P2PVS) is a popular approach to redistribute live media over the Internet. The proposed P2PVS solutions can be roughly classified in two classes:
P2Pビデオストリーミング（P2PVS）は、インターネット経由でライブメディアを再配布するための一般的なアプローチです。提案されているP2PVSソリューションは、大きく2つのクラスに分類できます。
o Push/Tree-based
o プッシュ/ツリーベース
o Pull/Mesh-based
o プル/メッシュベース
The Push/Tree-based solution creates an overlay network among Peers that has a tree shape [Castro03]. Using a progressive encoding (e.g., Multiple Description Coding or H.264 Scalable Video Coding), multiple trees could be set up to support video rate adaptation. On each tree, an enhancement stream is sent. The higher the number of received streams, the higher the video quality. A peer controls the video rate by either fetching or not fetching the streams delivered over the distribution trees.
プッシュ/ツリーベースのソリューションは、ツリー形状を持つピア間のオーバーレイネットワークを作成します[Castro03]。プログレッシブエンコーディング（Multiple Description CodingまたはH.264 Scalable Video Codingなど）を使用すると、複数のツリーを設定して、ビデオレートの適応をサポートできます。各ツリーで、拡張ストリームが送信されます。受信ストリーム数が多いほど、ビデオ品質が高くなります。ピアは、配信ツリーを介して配信されたストリームをフェッチするかフェッチしないかによって、ビデオレートを制御します。
The Pull/Mesh-based solution is inspired by the BitTorrent file sharing mechanism. A tracker collects information about the state of the swarm (i.e., the set of participating peers). A peer forms a mesh overlay network with a subset of peers and exchanges data with them. A peer announces what data items it disposes and requests missing data items that are announced by connected peers. In case of live streaming, the involved data set includes only a recent window of data items published by the source. Also, in this case, the use of a progressive encoding can be exploited for video rate adaptation.
プル/メッシュベースのソリューションは、BitTorrentファイル共有メカニズムに着想を得ています。トラッカーは、群れの状態（つまり、参加しているピアのセット）に関する情報を収集します。ピアは、ピアのサブセットでメッシュオーバーレイネットワークを形成し、ピアとデータを交換します。ピアは、破棄するデータアイテムをアナウンスし、接続されたピアによってアナウンスされた欠落データアイテムを要求します。ライブストリーミングの場合、関連するデータセットには、ソースによって公開されたデータアイテムの最近のウィンドウのみが含まれます。また、この場合、プログレッシブエンコーディングの使用をビデオレートの適応に利用できます。
Pull/Mesh-based P2PVS solutions are the more promising candidate for the ICN deployment, since most of ICN approach provides a pull-based API [Jacobson09b] [Detti11] [Chai11] [NETINF]. In addition, Pull/Mesh-based P2PVS are more robust than the Push/Tree-based one [Magharei07], and the PPSP working group [IETF-PPSP] is also proposing a Pull/Mesh-based solution.
ほとんどのICNアプローチはプルベースのAPI [Jacobson09b] [Detti11] [Chai11] [NETINF]を提供するため、プル/メッシュベースのP2PVSソリューションは、ICN展開のより有望な候補です。さらに、Pull / MeshベースのP2PVSは、Push / Treeベースの[Magharei07]よりも堅牢であり、PPSPワーキンググループ[IETF-PPSP]も、Pull / Meshベースのソリューションを提案しています。
+------------------------------------------------+
| |
| +--------------------------------+ |
| | Tracker | |
| +--------------------------------+ |
| | ^ ^ |
|Tracker | | Tracker |Tracker |
|Protocol| | Protocol |Protocol |
| | | | |
| V | | |
| +---------+ Peer +---------+ |
| | Peer |<----------->| Peer | |
| +---------+ Protocol +---------+ |
| | ^ |
| | |Peer |
| | |Protocol |
| V | |
| +---------------+ |
| | Peer | |
| +---------------+ |
| |
+------------------------------------------------+
Figure 1: PPSP System Architecture [RFC6972]
図1：PPSPシステムアーキテクチャ[RFC6972]
Figure 1 reports the PPSP architecture presented in [RFC6972]. PEERs announce and share video chunks and a TRACKER maintains a list of PEERs participating in a specific audio-video channel or in the distribution of a streaming file. The TRACKER functionality may be centralized in a server or distributed over the PEERs. PPSP standardizes the peer and Tracker Protocols, which can run directly over UDP or TCP.
図1は、[RFC6972]で提示されているPPSPアーキテクチャを報告しています。 PEERはビデオチャンクをアナウンスして共有し、TRACKERは特定のオーディオビデオチャネルまたはストリーミングファイルの配布に参加しているPEERのリストを維持します。 TRACKER機能は、サーバーに集中化することも、PEERに分散することもできます。 PPSPは、UDPまたはTCPで直接実行できるピアおよびトラッカープロトコルを標準化します。
This document discusses some preliminary concepts about the deployment of PPSP on top of an ICN that exposes a pull-based API, meanwhile considering the impact of MPEG-DASH streaming format.
このドキュメントでは、MPEG-DASHストリーミング形式の影響を考慮しながら、プルベースのAPIを公開するICNの上にPPSPを展開することに関するいくつかの予備的な概念について説明します。
The Peer-to-Peer Streaming Peer Protocol (PPSPP) is defined in [Bakker15] and the Peer-to-Peer Streaming Tracker Protocol (PPSP-TP) is defined in [RFC7846].
ピアツーピアストリーミングピアプロトコル（PPSPP）は[Bakker15]で定義されており、ピアツーピアストリーミングトラッカープロトコル（PPSP-TP）は[RFC7846]で定義されています。
Some of the operations carried out by the Tracker Protocol are the following: when a peer wishes to join the streaming session, it contacts the tracker (CONNECT message), obtains a PEER_ID and a list of PEER_IDs (and IP addresses) of other peers that are participating to the SWARM and that the tracker has singled out for the requesting peer (this may be a subset of the all peers of the SWARM); in addition to this join operation, a peer may contact the tracker to request to renew the list of participating peers (FIND message), to periodically update its status to the tracker (STAT_REPORT message), and so on.
トラッカープロトコルによって実行される操作の一部は次のとおりです。ピアがストリーミングセッションに参加したい場合、トラッカーに接続し（CONNECTメッセージ）、PEER_IDと他のピアのPEER_ID（およびIPアドレス）のリストを取得します。 SWARMに参加しており、トラッカーが要求側ピアを特定した（これはSWARMのすべてのピアのサブセットである場合があります）。この参加操作に加えて、ピアはトラッカーに連絡して、参加ピアのリストの更新を要求する（FINDメッセージ）、そのステータスをトラッカーに定期的に更新する（STAT_REPORTメッセージ）などの場合があります。
Some of the operations carried out by the Peer Protocol include the following: using the list of peers delivered by the tracker, a peer establishes a session with them (HANDSHAKE message); a peer periodically announces to neighboring peers which chunks it has available for download (HAVE message); using these announcements, a peer requests missing chunks from neighboring peers (REQUEST messages), which will be sent back to them (DATA message).
ピアプロトコルによって実行される操作には、次のものがあります。トラッカーによって配信されたピアのリストを使用して、ピアはそれらとのセッションを確立します（HANDSHAKEメッセージ）。ピアは、ダウンロードに使用できるチャンクを隣接ピアに定期的にアナウンスします（HAVEメッセージ）。これらのアナウンスを使用して、ピアは隣接するピアから欠落しているチャンクを要求し（REQUESTメッセージ）、それらはそれらに返送されます（DATAメッセージ）。
An ICN provides users with data items exposed by names. The bundle name and data item is usually referred as "named-data", "named-content", etc. To transfer PPSP messages through an ICN, the messages should be wrapped as named-data items and receivers should request them by name.
ICNは、名前で公開されるデータ項目をユーザーに提供します。バンドル名とデータアイテムは通常「名前付きデータ」、「名前付きコンテンツ」などと呼ばれます。ICNを介してPPSPメッセージを転送するには、メッセージを名前付きデータアイテムとしてラップし、受信者が名前で要求する必要があります。
A PPSP entity receives messages from peers and/or a tracker. Some operations require gathering the messages generated by another specific host (peer or tracker). For instance, if Peer A wishes to gain information about video chunks available from Peer B, the former shall fetch the PPSP HAVE messages specifically generated by the latter. We refer to these kinds of named-data as "located-named-data" since they should be gathered from a specific location (e.g., Peer B).
PPSPエンティティは、ピアやトラッカーからメッセージを受信します。一部の操作では、別の特定のホスト（ピアまたはトラッカー）によって生成されたメッセージを収集する必要があります。たとえば、ピアAがピアBから利用可能なビデオチャンクに関する情報を取得したい場合、前者は後者が特に生成したPPSP HAVEメッセージをフェッチします。これらの種類の名前付きデータは、特定の場所（ピアBなど）から収集する必要があるため、「location-named-data」と呼びます。
For other PPSP operations, such as fetching a DATA message (i.e., a video chunk), as long as a peer receives the requested content, it doesn't matter which endpoint generated the data. We refer to this information with the generic term "named-data".
DATAメッセージ（ビデオチャンクなど）のフェッチなどの他のPPSP操作の場合、ピアが要求されたコンテンツを受信する限り、どのエンドポイントがデータを生成したかは関係ありません。この情報を総称して「名前付きデータ」と呼びます。
The naming scheme differentiates named-data and located-named-data items. In the case of named-data, the naming scheme only includes a content identifier (e.g., the name of the video chunk) without any prefix identifying who provides the content. For instance, a DATA message containing the video chunk "#1" may be named as "ccnx:/swarmID/chunk/chunkID", where swarmID is a unique identifier of the streaming session, "chunk" is a keyword, and chunkID is the chunk identifier (e.g., an integer number).
命名体系は、名前付きデータと位置指定済みデータの項目を区別します。名前付きデータの場合、ネーミングスキームにはコンテンツ識別子（ビデオチャンクの名前など）のみが含まれ、誰がコンテンツを提供するかを識別する接頭辞は含まれません。たとえば、ビデオチャンク「＃1」を含むDATAメッセージの名前は「ccnx：/ swarmID / chunk / chunkID」とすることができます。ここで、swarmIDはストリーミングセッションの一意の識別子、「chunk」はキーワード、chunkIDはチャンク識別子（たとえば、整数）。
In case of located-named-data, the naming scheme includes a location-prefix, which uniquely identifies the host generating the data item. This prefix may be the PEER_ID in case the host was a peer or a tracker identifier in case the host was the tracker. For instance, a HAVE message generated by a Peer B may be named as "ccnx:/swarmID/peer/PEER_ID/HAVE", where "peer" is a keyword, PEER_ID_B is the identifier of Peer B, and HAVE is a keyword.
位置指定データの場合、命名スキームには、データ項目を生成するホストを一意に識別するロケーションプレフィックスが含まれます。このプレフィックスは、ホストがピアの場合はPEER_ID、ホストがトラッカーの場合はトラッカーIDになります。たとえば、ピアBによって生成されたHAVEメッセージは、 "ccnx：/ swarmID / peer / PEER_ID / HAVE"と名付けられます。ここで、 "peer"はキーワード、PEER_ID_BはピアBの識別子、HAVEはキーワードです。
The PPSP procedures are based both on pull and push interactions. For instance, the distribution of chunks availability can be classified as a push-based operation since a peer sends "unsolicited" information (HAVE message) to neighboring peers. Conversely, the procedure used to receive video chunks can be classified as pull-based since it is supported by a request/response interaction (i.e., REQUEST, DATA messages).
PPSPの手順は、プルとプッシュの両方の相互作用に基づいています。たとえば、ピアが隣接するピアに「要請されていない」情報（HAVEメッセージ）を送信するため、チャンクの可用性の分布はプッシュベースの操作として分類できます。逆に、ビデオチャンクを受信するために使用される手順は、要求/応答の相互作用（つまり、REQUEST、DATAメッセージ）によってサポートされるため、プルベースとして分類できます。
As we said, we refer to an ICN architecture that provides a pull-based API. Accordingly, the mapping of PPSP pull-based procedure is quite simple. For instance, using the CCN architecture [Jacobson09b], a PPSP DATA message may be carried by a CCN DATA message and a REQUEST message can be transferred by a CCN Interest.
前述のように、プルベースのAPIを提供するICNアーキテクチャについて言及します。したがって、PPSPプルベースの手順のマッピングは非常に簡単です。たとえば、CCNアーキテクチャ[Jacobson09b]を使用すると、PPSP DATAメッセージはCCN DATAメッセージによって伝送され、REQUESTメッセージはCCN Interestによって転送されます。
Conversely, the support of push-based PPSP operations may be more difficult. We need an adaptation functionality that carries out a push-based operation using the underlying pull-based service primitives. For instance, a possible approach is to use the request/ response (i.e., Interest/Data) four-way handshakes proposed in [Jacobson09a]. Another possibility is that receivers periodically send out request messages of the named-data that neighbors will push and, when available, the sender inserts the pushed data within a response message.
逆に、プッシュベースのPPSP操作のサポートはより難しい場合があります。基盤となるプルベースのサービスプリミティブを使用してプッシュベースの操作を実行する適応機能が必要です。たとえば、可能なアプローチは、[Jacobson09a]で提案された要求/応答（つまり、インタレスト/データ）の4ウェイハンドシェイクを使用することです。もう1つの可能性は、受信者が定期的に名前付きデータの要求メッセージを送信し、ネイバーがプッシュすることです。使用可能な場合、送信者はプッシュされたデータを応答メッセージ内に挿入します。
+-----------------------------------+
| Application |
+-----------------------------------+
| PPSP (TCP/IP) |
+-----------------------------------+
| ICN - PPSP Adaptation Layer (AL) |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
Figure 2: Mediator Approach
図2：メディエーターアプローチ
Figure 2 provides a possible abstract layering for PPSP over ICN. The Adaptation Layer acts as a mediator (proxy) between legacy PPSP entities based on TCP/IP and the ICN architecture. In fact, the role the mediator is to use ICN to transfer PPSP legacy messages.
図2は、PPSP over ICNの可能な抽象化レイヤーを示しています。適応層は、TCP / IPに基づくレガシーPPSPエンティティとICNアーキテクチャの間のメディエーター（プロキシ）として機能します。実際、メディエーターがICNを使用してPPSPレガシーメッセージを転送する役割です。
This approach makes it possible to merely reuse TCP/IP P2P applications whose software includes also PPSP functionality. This "all-in-one" development approach may be rather common since the PPSP application interface is not going to be specified. Moreover, if the operating system will provide libraries that expose a PPSP API, these will be initially based on an underlying TCP/IP API. Also, in this case, the mediator approach would make it possible to easily reuse both the PPSP libraries and the Application on top of an ICN.
このアプローチにより、ソフトウェアにPPSP機能も含まれるTCP / IP P2Pアプリケーションを単に再利用することが可能になります。 PPSPアプリケーションインターフェイスが指定されないため、この「オールインワン」開発アプローチはかなり一般的かもしれません。さらに、オペレーティングシステムがPPSP APIを公開するライブラリを提供する場合、これらは最初に基礎となるTCP / IP APIに基づいています。また、この場合、メディエーターアプローチを使用すると、PPSPライブラリとアプリケーションの両方をICNの上で簡単に再利用できます。
+-----------------------------------+
| Application |
+-----------------------------------+
| ICN-PPSP |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
Figure 3: Clean-Slate Approach
図3：クリーンスレートアプローチ
Figure 3 sketches a clean-slate layering approach in which the application directly includes or interacts with a PPSP version based on ICN. It's likely such a PPSP_ICN integration could yield a simpler development also because it does not require implementing a TCP/IP to ICN translation as in the Mediator approach. However, the clean-slate approach requires developing the application (in case of embedded PPSP functionality) or the PPSP library from scratch without exploiting what might already exist for TCP/IP.
図3は、アプリケーションがICNに基づくPPSPバージョンを直接含むか、またはそれとやり取りする、白紙の階層化アプローチを示しています。メディエーターアプローチのようにTCP / IPからICNへの変換を実装する必要がないため、このようなPPSP_ICN統合はより単純な開発をもたらす可能性があります。ただし、白紙の方法では、TCP / IPの既存の機能を利用せずに、アプリケーション（埋め込みPPSP機能の場合）またはPPSPライブラリをゼロから開発する必要があります。
Overall, the Mediator approach may be considered the first step of a migration path towards ICN-native PPSP applications.
全体として、メディエーターアプローチは、ICNネイティブのPPSPアプリケーションへの移行パスの最初のステップと見なすことができます。
Upon the ICN API, a user (peer) requests content and the ICN sends it back. The content is gathered by the ICN from any source, which could be the closest peer that disposes of the named-data item, an in-network cache, etc. Actually, "where" to gather the content is controlled by an underlying ICN routing plane, which sets up the ICN forwarding tables (e.g., CCN FIB [Jacobson09b]).
ICN APIで、ユーザー（ピア）がコンテンツをリクエストし、ICNがコンテンツを送り返します。コンテンツは、任意のソースからICNによって収集されます。これは、名前付きデータアイテム、ネットワーク内キャッシュなどを破棄する最も近いピアである可能性があります。実際、コンテンツを収集する「場所」は、基になるICNルーティングによって制御されます。 ICN転送テーブルをセットアップするプレーン（CCN FIB [Jacobson09b]など）。
A cross-layer interaction between the ICN routing plane and the PPSP may be required to support a PPSP session. Indeed, ICN shall forward request messages (e.g., CCN Interest) towards the proper peer that can handle them. Depending on the layering approach, this cross-layer interaction is controlled either by the Adaptation Layer or by the ICN-PPSP. For example, if a Peer A receives a HAVE message indicating that Peer B disposes of the video chunk named "ccnx:/swarmID/chunk/chunkID", then the former should insert in its ICN forwarding table an entry for the prefix "ccnx:/swarmID/chunk/ chunkID" whose next hop locator (e.g., IP address) is the network address of Peer B [Detti13].
ICNルーティングプレーンとPPSP間のクロスレイヤー相互作用は、PPSPセッションをサポートするために必要になる場合があります。実際、ICNは、要求メッセージ（CCNインタレストなど）を、それらを処理できる適切なピアに転送します。レイヤー化アプローチに応じて、このクロスレイヤー相互作用は、適応レイヤーまたはICN-PPSPのいずれかによって制御されます。たとえば、ピアAがピアBが「ccnx：/ swarmID / chunk / chunkID」という名前のビデオチャンクを破棄することを示すHAVEメッセージを受信した場合、前者はICN転送テーブルにプレフィックス「ccnx：」のエントリを挿入する必要があります。 / swarmID / chunk / chunkID "のネクストホップロケータ（IPアドレスなど）は、ピアBのネットワークアドレスです[Detti13]。
The ICN functionality that supports a PPSP session may be "isolated" or "integrated" with one from a public ICN.
PPSPセッションをサポートするICN機能は、パブリックICNの機能と「分離」または「統合」される場合があります。
In the isolated case, a PPSP session is supported by an instance of an ICN (e.g., deployed on top of an IP) whose functionalities operate only on the limited set of nodes participating to the swarm, i.e., peers and the tracker. This approach resembles the one followed by a current P2P application, which usually forms an overlay network among peers of a P2P application; intermediate public IP routers do not carry out P2P functionalities.
孤立したケースでは、PPSPセッションは、その機能がスウォームに参加しているノードの限られたセット（つまり、ピアとトラッカー）でのみ動作するICN（IPの上に配置されているなど）のインスタンスによってサポートされています。このアプローチは、現在のP2Pアプリケーションに続くアプローチに似ています。これは、通常、P2Pアプリケーションのピア間でオーバーレイネットワークを形成します。中間のパブリックIPルーターはP2P機能を実行しません。
In the integrated case, the nodes of a public ICN may be involved in the forwarding and in-network caching procedures. In doing so, the swarm may benefit from the presence of in-network caches, thus limiting uplink traffic on peers and inter-domain traffic, too. These are distinctive advantages of using PPSP over a public ICN rather than over TCP/IP. In addition, such advantages aren't likely manifested in the case of isolated deployment.
統合されたケースでは、パブリックICNのノードが転送およびネットワーク内キャッシング手順に関与する場合があります。そうすることで、スウォームはネットワーク内キャッシュの存在から恩恵を受けることができ、ピアのアップリンクトラフィックとドメイン間トラフィックも制限されます。これらは、TCP / IPではなくパブリックICNを介してPPSPを使用する際の特有の利点です。さらに、分離された展開の場合、そのような利点はおそらく現れません。
However, the possible interaction between the PPSP and the routing layer of a public ICN may be dramatic, both in terms of explosion of the forwarding tables and in terms of security. These issues specifically take place for those ICN architectures for which the name resolution (i.e., name to next hop) occurs en route, like the CCN architecture.
ただし、PPSPとパブリックICNのルーティングレイヤーとの間の可能な相互作用は、転送テーブルの爆発とセキュリティの両方の点で劇的です。これらの問題は、CCNアーキテクチャのように、名前解決（つまり、名前からネクストホップ）が途中で発生するICNアーキテクチャで特に発生します。
For instance, using the CCN architecture, to fetch a named-data item offered by a Peer A the on-path public ICN entities have to route the request messages towards the Peer A. This implies that the ICN forwarding tables of public ICN nodes may contain many entries, e.g., one entry per video chunk, and these entries are difficult to be aggregated since peers may have available only sparse parts of a big content, whose names have a same prefix (e.g., "ccnx:/swarmID"). Another possibility is to wrap all PPSP messages into a located-named-data. In this case, the forwarding tables should contain "only" the PEER_ID prefixes (e.g., "ccnx:/swarmID/peer/PEER_ID"), thus scaling down the number of entries from number of chunks to number of peers. However, in this case, the ICN mechanisms recognize the same video chunk offered by different peers as different content, thus losing caching and multicasting ICN benefits. In any case, routing entries should be updated either on the basis of the availability of named-data items on peers or on the presence of peers, and these events in a P2P session are rapidly changing and possibly hampering the convergence of the routing plane. Finally, since peers have an impact on the ICN forwarding table of public nodes, this may open obvious security issues.
たとえば、CCNアーキテクチャを使用して、ピアAが提供する名前付きデータアイテムをフェッチするには、オンパスのパブリックICNエンティティがリクエストメッセージをピアAにルーティングする必要があります。これは、パブリックICNノードのICN転送テーブルがたとえば、ビデオチャンクごとに1つのエントリなど、多くのエントリが含まれています。ピアは、名前の接頭辞が同じである大きなコンテンツのスパース部分のみを使用できるため（たとえば、 "ccnx：/ swarmID"）、これらのエントリを集約することは困難です。別の可能性は、すべてのPPSPメッセージを特定の名前付きデータにラップすることです。この場合、転送テーブルには「のみ」のPEER_IDプレフィックス（たとえば、「ccnx：/ swarmID / peer / PEER_ID」）を含める必要があるため、チャンクの数からピアの数にエントリ数を減らします。ただし、この場合、ICNメカニズムは、異なるピアによって提供される同じビデオチャンクを異なるコンテンツとして認識するため、ICNのキャッシングとマルチキャストの利点が失われます。いずれの場合でも、ルーティングエントリは、ピアでの名前付きデータアイテムの可用性またはピアの存在に基づいて更新する必要があります。P2Pセッションでのこれらのイベントは急速に変化し、ルーティングプレーンの収束を妨げる可能性があります。最後に、ピアはパブリックノードのICN転送テーブルに影響を与えるため、これは明らかなセキュリティ問題を引き起こす可能性があります。
The introduction of video rate adaptation may significantly decrease the effectiveness of P2P cooperation and of in-network caching, depending of the kind of the video coding used by the MPEG-DASH stream.
ビデオレートアダプテーションの導入により、MPEG-DASHストリームで使用されるビデオコーディングの種類によっては、P2P連携やネットワーク内キャッシュの効果が大幅に低下する可能性があります。
In case of an MPEG-DASH streaming with MPEG AVC encoding, the same video chunk is independently encoded at different rates and the encoding output is a different file for each rate. For instance, in case of a video encoded at three different rates, R1, R2, and R3; for each segment S, we have three distinct files: S.R1, S.R2, and S.R3. These files are independent of each other. To fetch a segment coded at R2 kbps, a peer shall request the specific file S.R2. Receiver-driven algorithms, implemented by the video client, usually handle the estimation of the best coding rate.
MPEG AVCエンコーディングを使用したMPEG-DASHストリーミングの場合、同じビデオチャンクは異なるレートで個別にエンコードされ、エンコーディング出力は各レートで異なるファイルになります。たとえば、R1、R2、R3の3つの異なるレートでエンコードされたビデオの場合。各セグメントSには、S.R1、S.R2、S.R3の3つの異なるファイルがあります。これらのファイルは互いに独立しています。 R2 kbpsでコード化されたセグメントをフェッチするには、ピアは特定のファイルS.R2を要求する必要があります。ビデオクライアントによって実装されるレシーバー駆動アルゴリズムは、通常、最高のコーディングレートの推定を処理します。
The independence among files associated with different encoding rates and the heterogeneity of peer bandwidths may dramatically reduce the interaction among peers, the effectiveness of in-network caching (in case of integrated deployment), and consequently, the ability of PPSP to offload the video server (i.e., a seeder peer). Indeed, a Peer A may select a coding rate (e.g., R1) different from the one selected by a Peer B (e.g., R2), and this prevents the former from fetching video chunks from the latter since Peer B only has chunks available that are coded at a rate different from the ones needed by Peer A. To overcome this issue, a common distributed rate selection algorithm could force peers to select the same coding rate [Detti13]; nevertheless, this approach may be not feasible in the case of many peers.
異なるエンコーディングレートとピアの帯域幅の不均一性に関連するファイル間の独立性により、ピア間の相互作用、ネットワーク内キャッシュの効果（統合された展開の場合）、およびPPSPがビデオサーバーの負荷を軽減する能力が劇的に低下する可能性があります（つまり、シードピア）。実際、ピアAは、ピアB（R2など）によって選択されたものとは異なるコーディングレート（R1など）を選択でき、ピアBは使用可能なチャンクしか持っていないため、前者は後者からビデオチャンクをフェッチできません。この問題を克服するために、一般的な分散レート選択アルゴリズムは、ピアに同じコーディングレートを選択させることができます[Detti13]。それにもかかわらず、このアプローチは、多くのピアの場合には実行できない場合があります。
The use of an SVC encoding (Annex G extension of the H.264/MPEG-4 Advanced Video Coding (AVC) video compression standard) should make rate adaptation possible while neither reducing peer collaborations nor the in-network caching effectiveness. For a single video chunk, an SVC encoder produces different files for the different rates (roughly "layers"), and these files are progressively related to each other. Starting from a base layer that provides the minimum rate encoding, the next rates are encoded as an "enhancement layer" of the previous one. For instance, in case the video is coded with three rates, R1 (base layer), R2 (enhancement layer n.1), and R3 (enhancement layer n.2), then for each DASH segment, we have three files: S.R1, S.R2, and S.R3. The file S.R1 is the segment coded at the minimum rate (base layer). The file S.R2 enhances S.R1, so S.R1 and S.R2 can be combined to obtain a segment coded at rate R2. To get a segment coded at rate R2, a peer shall fetch both S.R1 and S.R2. This progressive dependence among files that encode the same segment at different rates makes peer cooperation possible, also in case peers player have autonomously selected different coding rates. For instance, if Peer A has selected the rate R1, the downloaded files S.R1 are useful also for a Peer B that has selected the rate R2, and vice versa.
SVCエンコーディング（H.264 / MPEG-4 Advanced Video Coding（AVC）ビデオ圧縮規格のアネックスG拡張）を使用すると、ピアのコラボレーションやネットワーク内のキャッシュ効率を低下させることなく、レート調整が可能になります。単一のビデオチャンクの場合、SVCエンコーダーは異なるレート（ほぼ「レイヤー」）の異なるファイルを生成し、これらのファイルは徐々に相互に関連付けられます。最小レートエンコーディングを提供するベースレイヤーから開始して、次のレートは前のレートの「エンハンスメントレイヤー」としてエンコードされます。たとえば、ビデオが3つのレート、R1（ベースレイヤー）、R2（エンハンスメントレイヤーn.1）、およびR3（エンハンスメントレイヤーn.2）でコーディングされている場合、各DASHセグメントに3つのファイルがあります。S .R1、S.R2、およびS.R3。ファイルS.R1は、最小レート（ベースレイヤー）でコーディングされたセグメントです。ファイルS.R2はS.R1を拡張するため、S.R1とS.R2を組み合わせて、レートR2でコーディングされたセグメントを取得できます。レートR2でコード化されたセグメントを取得するには、ピアはS.R1とS.R2の両方をフェッチする必要があります。同じセグメントを異なるレートでエンコードするファイル間のこの漸進的な依存関係により、ピアプレーヤーが異なるコーディングレートを自律的に選択した場合にも、ピアの協調が可能になります。たとえば、ピアAがレートR1を選択した場合、ダウンロードされたファイルS.R1は、レートR2を選択したピアBにも役立ちます。逆も同様です。
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.
IPTVは、インターネット経由でブロードキャストされる高品質のコンテンツの配信を指し、通常は厳密な品質要件に関連付けられています。つまり、500 ms未満の知覚遅延と、現在の損失率より数倍低いパケット損失率です。最も一般的に使用されるアクセスネットワーク（[ATIS-IIF]を参照）。 IPTVサービスを提供する上での主な課題は次のとおりです。
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:
チャネル変更待ち時間は、IPTVサービスの主要な懸念事項です。チャネル変更中に知覚される遅延は500ミリ秒未満である必要があります。 IPインフラストラクチャでこの目標を達成するには、複数の選択肢があります。
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
iiネットワーク内の他のピアに接続します（効率はピアサポートに依存し、専用サーバーでサポートされている場合、効果的でリソース効率が良い）。そして
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).
iii一度に複数のマルチキャストセッションに接続します（効果的ですが、リソース効率はよくなく、ユーザーアクティビティの追跡に使用される予測モデルの精度に依存します）。
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).
2番目の大きな課題は、エラーの回復です。一般的なIPTVサービス要件では、アーティファクト間の平均時間は約2時間です（[ATIS-IIF]を参照）。これは、知覚損失率が10 ^ -7以下であることを示唆しています。現在のIPベースのソリューションは、次の予防的および事後的回復技術に依存しています。損失シナリオ）; （ii）専用サーバーへのユニキャスト回復要求の作成（サービスプロバイダーからのアクティブサポートが必要）。 （iii）ピアを調べて修復パケットを取得する（一致するピアを見つけて、それらの連携を有効にすることも別の課題です）。
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.
ICNは、IPTVトラフィックの配信に大きな利点をもたらします。たとえば、ICNは本質的にマルチキャストをサポートし、パケット損失からの迅速な回復を可能にします（ネットワーク内キャッシュの助けを借りて）。同様に、ピアサポートもネットワーク内キャッシュの形で提供され、通常は2つのピア間の仲介者として機能するため、IPTVコンテンツへのより早いアクセスが可能になります。
However, despite these advantages, delivery of IPTV service over ICNs brings forth new challenges. We can list some of these challenges as follows:
ただし、これらの利点にもかかわらず、ICNを介したIPTVサービスの配信は、新たな課題をもたらします。これらの課題のいくつかを次のようにリストできます。
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 bandwidth fluctuations).
oメッセージングのオーバーヘッド：ICNはプルベースのアーキテクチャであり、要求と応答の間の一意のバランスに依存しています。ユーザーは各データパケットに対して要求を行う必要があります。 15 Mbpsを超える（そしてその可能性が高い）レートのIPTVの場合、これらのストリームをもたらすためにアップストリームに大量のトラフィックが観察されます。ストリームの数が増えると（異なる品質レベルでの同じセッションや他のフォーマットを含む）、ルーターへの負担も増えます。リクエストの大部分がコアで集約されている場合でも、エッジに近いルーター（ユーザーリクエストで最大の相違が見られる場所）では、これらのリクエストを処理するためのオーバーヘッドが大幅に増加します。アップリンクの使用量がユーザーが要求するセッション数で増加するため（たとえば、帯域幅の変動の影響を最小限に抑えるため）、ユーザー側でも同じことが言えます。
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 キャッシュ制御：IPTVコンテンツが急速に期限切れになる（おそらく1秒の有効期限しきい値がある）ため、インテリジェントに選択された命名規則を使用して、他のキャッシュされたコンテンツへの劣化の影響を防ぐために、そのようなコンテンツを効果的にフラッシュするソリューションが必要です。 。ただし、迅速な回復を可能にし、セッションへのアクセス時間を最適化するには（現在または新しいユーザーから）、そのような有効期限のタイミングをネットワーク負荷とユーザーの需要に適応させる必要があります。ただし、必要に応じて、以前のコンテンツへの迅速なアクセスもサポートする必要があります。たとえば、ユーザーが巻き戻し機能にアクセスする場合（ネットワーク内のキャッシュは、そのようなコンテンツを維持するために必要なオーバーヘッドのため、このようなシナリオではあまり役に立ちません）。
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 undesired pauses.
o アクセスの正確性：最新のセッションデータを受信するには、ユーザーはリクエスト時にそのような情報に注意する必要があります。 IPマルチキャストとは異なり、ユーザーは間接的にセッションに参加するため、バッファリングの遅延を最小限に抑え、起動の待ち時間を短縮するには、セッション情報が重要です。このような情報がなく、中間ルーターからの積極的な協力がなければ、古いデータはコンテンツ配信の効率を著しく損なう可能性があります。さらに、最初のコンテンツアクセスポイントのルックアヘッドレイテンシのライフタイムは当初の意図よりも短い可能性があるため、キャッシュを見つけることは必ずしもセッションに参加することと同じではありません。たとえば、間接マルチキャストを開始したユーザーがセッションを早く終了した場合、残りのユーザーからの要求は、コンテンツソースに向かうときに1つのRTTの追加の遅延を経験する必要があります。中間ルーターへの近さに応じて起動待ち時間が選択されている場合、セッション中のコンテンツソースにアクセスすると、望ましくない一時停止が発生する可能性があります。
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).
IPTVにはマルチキャストだけではないことに注意してください。多くの実装には、マルチキャストセッションを複数のユニキャストセッションに変換する「トリックプレイ」（早送り、一時停止、巻き戻し）が含まれています。このコンテキストでは、キャッシングは暗黙的なマルチキャストを提供しますが、2人の異なるユーザー間の厳密な同期制約がないため、ICNは有益です。 1人のユーザーが巻き戻して再び再生を開始し、別のユーザーが最近表示したコンテンツの近くのキャッシュから描画する場合があります（厳密なマルチキャストセッションでは、1人のユーザーが遅れをとる機会を実装するのはより困難です）。
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.
このセクションでは、ICNを介したマルチメディアストリーミングのためのDRM機能の必要性について説明します。 ICNでDRMをサポートするように認証、承認、およびアカウンティング（AAA）を変更することと、ブロードキャスト暗号化を使用することの2つの可能なアプローチに焦点を当てています。
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.
ICNはデジタルコンテンツの普及に多用されることが想定されています。デジタルコンテンツの配信にはDRMを検討することが重要です。今日のインターネットでは、オンデマンドビデオストリーミング用の2つの主要なビジネスモデルのクラスがあります。最初のモデルは広告収入に基づいています。著作権で保護されていない（通常はユーザー生成コンテンツ（UGC））コンテンツは、Google（YouTube）などの大規模なインフラストラクチャプロバイダーから無料で提供されます。インフラストラクチャは、コンテンツに接合された広告によって賄われています。この文脈では、UGCのプロデューサーは最大限の普及を目指して努力するだけなので、DRMの考慮は必要ないかもしれません。 UGCの一部のプロデューサーは、主に家族、友人、大学などとコンテンツを共有することに関心があり、利益を上げる意図はありません。ただし、これらのエンティティは主に利益志向であるため、ビジネスモデルの2番目のクラスにはDRMが必要です。たとえば、大規模なオンデマンドストリーミングプラットフォーム（Netflixなど）は、サブスクリプションに基づいてビジネスモデルを確立します。 TVシリーズ、映画、音楽などの著作権保護されたコンテンツにアクセスするために、消費者は月額料金を支払う必要がある場合があります。このモデルは、広告でサポートされ、YouTubeチャンネルやSpotifyなどのコンテンツ利用者に無料で提供される場合がありますが、コンテンツの作成者は彼の作品に対していくらかの報酬を期待しています。サービスプロバイダーと著作権所有者の観点からは、料金を支払う（明示的または暗黙的に広告配置を通じて）クライアントのみがコンテンツにアクセスして使用できる必要があります。とにかく、課題は、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).
このセクションでは、ICN通信パラダイムに準拠したDRM機能の適切な基礎としてのブロードキャスト暗号化（BE）について説明します（ネットワーク固有のキャッシング、BEの利点と見なされる点が強調されます）。
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 audio-visual content.
ICNでは、データパケットは本質的にネットワークにキャッシュされ、ネットワークの参加者はこれらのパケットのコピーを要求できます。これにより、ICNを介して配布されるコンテンツのアクセス制御を実装することが非常に困難になります。素朴なアプローチは、消費者ごとに送信されるデータを個別の鍵で暗号化することです。これにより、対象となる消費者以外の誰もがデータを復号化して使用することが禁止されます。ただし、このアプローチは、固有のネットワークキャッシングから得られる利点を減らすため、ICNの通信パラダイムには適していません。複数のコンシューマーが同じコンテンツを要求しても、このアプローチを使用すると、各コンシューマーに要求されるデータは異なります。より良い、しかしまだ不十分なアイデアは、すべての消費者に対して単一のキーを使用することです。これはICNのキャッシング機能の利点を損なうものではありません。欠点は、消費者の1人がキーを不正に配布した場合、システムが破損することです。ネットワーク内の任意のエンティティがデータにアクセスできます。このようなイベントの後にキーを変更しても、プロバイダーは違法なディストリビューターを特定することができないため、役に立ちません。したがって、この人物が新しいキーを再度配布するのを止めることはできません。この問題に加えて、他の課題も考慮する必要があります。サブスクリプションは一定の時間が経過すると期限切れになり、これらのコンシューマがコンテンツにアクセスできなくなることを保証する必要があります。毎日数百万人の消費者にサービスを提供するプロバイダー（Netflixなど）の場合、1日あたりの有効期限が切れるサブスクリプションがかなりの数になる可能性があります。サブスクリプションの有効期限が切れるたびに新しいキーを公開するには、視聴覚コンテンツのコレクションを再暗号化するためだけに、不適切な量の計算能力が必要になります。
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.
これらの課題を解決するための可能なアプローチは、[Posch13]で提案されているBE [Fiat94]です。これ以降、このセクションでは、ICNビデオストリーミングの使用例におけるDRM機能のイネーブラーとしてのBEのみに焦点を当てます。このサブセクションでは、BEの動作の説明を続け、ICNでのコンテンツ配信のコンテキストでBEを使用してアクセス制御スキームを実装する方法を示します。
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:
BEは実際には誤解を招く名前を持っています。具体的な暗号化スキームを期待できます。ただし、キー管理スキームのファミリーに属しています。これらのスキームは、暗号化キーの生成、交換、保存、および交換を担当します。 BEスキームの最も興味深い特性は次のとおりです。
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 BEスキームは通常、事前に生成された一連のシークレットをすべての参加者に分散する責任を負う、ライセンスエージェント（LA）と呼ばれるグローバルな信頼エンティティを使用します。各参加者は、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 参加者は、LAによって選択される共通のセッションキーに同意できます。 LAは、キーを含む暗号化されたメッセージをブロードキャストします。シークレットの有効なセットを持つ参加者は、このメッセージからセッションキーを取得できます。
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 new key.
o システムの参加者数は動的に変化する可能性があります。エンティティは、いつでもコミュニケーショングループに参加したり、グループから脱退したりできます。新しいエンティティが参加すると、LAはそのエンティティに有効な秘密のセットを渡します。エンティティが離脱する（または強制的に離脱する）と、LAはエンティティのキーのサブセットを取り消します。つまり、LAが新しいキーを配布するときに、正しいセッションキーを導出できなくなります。
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 schemes.
o 裏切り者（秘密を明らかにするエンティティ）を追跡し、進行中の通信から除外することができます。裏切り者を特定するためのアルゴリズムと前提条件は、具体的な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:
このリストは、BEがICN経由で配布されるデータへのアクセスを制御するのに適している理由をすでに示しています。 BEを使用すると、動的に変化するサブセットまたはネットワーク参加者間の機密データ伝送に単一のセッションキーを使用できます。データはすべての正当なクライアントが知っている単一のキーでのみ暗号化されるため、ICNキャッシュを利用できます。さらに、裏切り者を特定してシステムから削除することができます。参加者を除外する必要がある場合、LAは最終的にセッションキーを更新するため、再暗号化の問題は依然として存在します。ただし、この不利な点は、次の点を考慮すればある程度緩和できます。
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 セッションキーの更新は、一連の不正使用された秘密が収集されるまで遅延する可能性があります。秘密は2つの理由で危険にさらされる可能性があることに注意してください。第1に、裏切り者が秘密を違法に明らかにした可能性があります。次に、エンティティのサブスクリプションが期限切れになりました。失効の遅延により、一部の不正なエンティティがコンテンツを一時的に使用できるようになります。ただし、これはホームエンターテイメントシナリオでは深刻な問題ではありません。定期的（短すぎない）間隔でセッションキーを更新することは、適切なトレードオフです。間隔が長くなるほど、コンテンツの再暗号化に必要な計算リソースが少なくなり、ICNのキャッシュ使用率が向上します。以前のセッションキーで暗号化されたICNキャッシュから古いデータを削除するために、パブリッシャーは送信パケットのライフタイムを示すことができます。
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 コンテンツはリクエスト時に動的に再暗号化する必要があります。これには、2つのセッションキーの更新中にコンテンツが要求されない場合、未使用のコンテンツが再暗号化されないという利点があります。したがって、リソースが無駄になることはありません。さらに、更新が非ピーク時にトリガーされる場合、ピーク時には一般により多様なコンテンツが要求されるため、ある時点で必要なリソースの最大量を効果的に減らすことができます。
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.
o 必要な計算リソースの量は時々大きく変動する可能性があるため、ストリーミングプロバイダーがクラウドベースのサービスを使用して、必要なリソースを現在のニーズに動的に適合させることができると有益です。計算時間または帯域幅の不足に関しては、クラウドサービスを使用して、不足を克服するためにスケールアップできます。
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.
図4は、ICNインフラストラクチャに基づいて構築され、DASHなどの動的適応ストリーミングの概念を使用するマルチメディア配信フレームワークでのBEの潜在的な使用法を示しています。 BEは、マルチメディアコンテンツへのアクセス制御の効率的でスケーラブルな方法を実現するために上部に実装されます。
+--------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 BE
図4：BEを使用した潜在的なマルチメディアフレームワーク
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 more operational.
最近、DRMを通常のネットワーク管理操作にリンクするためのDRMへの新しいアプローチが登場し、DRMをAAAサービスにリンクしています。 ICNは、コンテンツが名前で要求され、どこからでも提供できるアーキテクチャの抽象化を提供します。 DRMでは、コンテンツプロバイダー（コンテンツの作成元）により、送信先（エンドユーザーアカウント）がコンテンツを使用できるようになります。コンテンツプロバイダーとコンテンツストレージ/キャッシュは、ITUキャリアコード（ICC）の2つの異なるエンティティにあります。従来のDRMの場合、ソースと宛先のみがカウントされ、中間ストレージはカウントされません。提案されたソリューションにより、キャッシングのプロバイダーは、よく知られたAAAメカニズムを使用してDRMポリシーに関与することができます。このソリューションは、このドキュメントの前半で提案されたBEの提案と互換性があることに注意することが重要です。 BEは、このソリューションの運用性が高いため、テクノロジーを提案しています。
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.
提案されたAAAベースのDRMを使用すると、特定の宛先から名前でコンテンツが要求されると、要求は従来のAAAメカニズムを介してコンテンツプロバイダーとキャッシングプロバイダーの両方にリンクし、コンテンツの保存場所とは無関係に適切なDRMポリシーをトリガーできます。 。このアプローチでは、キャッシング、DRM、およびAAAは独立したエンティティのままですが、ICNメカニズムを通じて連携できます。提案されたソリューションは、コンテンツプロバイダーによって行われていた従来のDRMを、コンテンツプロバイダーとネットワーク/キャッシングプロバイダーによって共同で行われるように拡張することを可能にします。
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.
ソリューションは「トークン」の概念に基づいています。コンテンツプロバイダーはエンドユーザーを認証し、暗号化されたトークンを発行して、ユーザーがアクセスできる名前付きコンテンツIDを認証します。トークンはネットワークプロバイダーと共有され、AAAプロトコルへのインターフェイスとして使用されます。この時点で、すべてのコンテンツアクセスはネットワークプロバイダーとICNの制御下にあります。コントローラとスイッチは、コンテンツ要求を管理し、モビリティを処理できます。トークンが有効であるか、コンテンツがネットワークで利用可能である限り、どこからでもコンテンツにアクセスできます。このようなスキームでは、名前付きコンテンツが要求されるたびにコンテンツプロバイダーに連絡する必要はありません。これにより、コンテンツプロバイダーネットワークの負荷が軽減され、ICNネットワークの分散キャッシングとピアツーピアストレージの特性により適したDRMメカニズムが作成されます。特に、名前で要求されたコンテンツは、トークンがコンテンツアクセスに有効であることをストレージ/キャッシュが確認できるという唯一の条件の下で、どこからでも提供できます。
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.
トークンはユーザーアカウント、場所、ハードウェア（メディアアクセス制御（MAC）アドレスなど）に基づいて発行できるため、このソリューションはコンテンツとネットワークプロバイダーの両方のニーズに完全にカスタマイズ可能であり、レガシー認証メカニズムに自然にリンクします。さらに、コンテンツプロバイダーとネットワークプロバイダーの両方がDRMポリシーに関与しているため、汚染攻撃やコンテンツに対するその他の違法な要求をより簡単に検出できます。提案されているAAAベースのDRMは現在完全に開発中です。
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.
オンラインビデオサービスの爆発的な増加は、モバイルワイヤレス端末による消費の増加とともに、ビデオアダプテーションを活用するICNメカニズムの課題をさらに悪化させています。以下のセクションでは、これらの課題から導き出された一連の調査項目を示し、この主題の次のステップをさらに紹介します。
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 significant benefits.
スタジアムでのスポーツイベント、コンサート、大規模なデモンストレーションなどの大規模なイベントでローカルコミュニケーションを使用してコンテンツ、特にビデオを配信することは、活発な調査分野であり、ICNが大きなメリットをもたらす可能性のあるユースケースです。
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.
このようなユースケースには、オンザフライで生成されるコンテンツの検索が含まれ、共有メカニズムに加えて検出メカニズムが必要です。ディストリビューションのスケーラビリティも重要になります。
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 above.
ビデオ会議の現在のプロトコルは設計されており、このドキュメントはそれらから入力を取り、主要な研究課題を特定します。リアルタイム通信は、上記のシナリオに（遅延の点でも同期の点でも）タイミングの制約を追加します。
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 inherently unicast.
アクセスルーター（AR）と仮想ルーター（VR）、および一般的な没入型マルチメディアエクスペリエンスは、複数のユーザーからの複数のデータストリームを1つのまとまりのあるものに結合するため、明らかにさらなる調査の領域です。これにより、ICNが本質的にユニキャストであるIPよりも自然な方法で処理できるようにマルチソース、マルチデスティネーションマルチメディアストリームの問題が発生します。
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 streams.
ICNの利点の1つは、ネットワークがデータ転送の途中でキャッシュを挿入できることです。これは、将来の再利用のためにコンテンツをキャッシュすることにより、ネットワーク全体の帯域幅需要を削減するために使用できますが、ビデオストリームを最適化する機会が増えます。
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.
たとえば、次のシナリオを考えてみます。クライアントがICNネットワークを介してサーバーに接続されています。クライアントが、WANを介してサーバーに接続されているキャッシュ機能を持つノードにワイヤレスで接続されているとしましょう。さらに、各リンク（ワイヤレスリンクとWAN論理リンクの両方）の容量が時間とともに変化するとします。
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 link.
レートアダプテーションがDASHなどの現在のメカニズムのようにエンドツーエンドで提供される場合、クライアントでサポートできる最大レートは、各リンクの最小帯域幅のレートです。
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.
たとえば、期間1の間にワイヤレス容量が1で有線容量が2であり、期間2の間にワイヤレス容量が2（ホットスポットのため）であり、有線容量が1（ネットワーク内の輻輳のため）である場合）の場合、達成可能な最高のエンドツーエンドレートは、各期間で1です。
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 periods.
ただし、期間1でキャッシュを使用して2ユニットのデータをプリフェッチした場合、期間2でキャッシュに1ユニットのデータがあり、サーバーからストリーミングできる別のデータユニットがあります。したがって、達成できるレートは2ユニットのデータです。この場合、平均帯域幅は2つの期間にわたって1から1.5に上昇します。
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).
このストローマンの例は、a）ネットワークのスループットを向上させるためのICNの利点、およびb）このゲインを利用するように設計される特別なレート適応メカニズムの必要性を示しています。エンドツーエンドのレート調整では、キャッシュの可用性を利用できません。 [Rainer16]の作成者は、バッファベースの適応メカニズムがこの課題に取り組むための1つのアプローチになり得ることを示しました。バッファベースの適応では、利用可能な帯域幅リソースが推定されないため（ビデオバッファの充填状態のみが考慮されます）、キャッシュヒットによって引き起こされる測定された帯域幅の変動は存在しません。したがって、それらは適応の決定に悪影響を与えることはできません（たとえば、頻繁な表現の切り替え）。
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.
モバイルデバイスからアクセスされるオンラインサービスの増加に伴い、事業者はさまざまな重複するワイヤレスアクセスネットワーキングテクノロジーを展開しています。このようにして、同じエリア内で、ユーザー端末は異なるセルラー、Wi-Fi、またはマイクロウェーブアクセス（WiMAX）ネットワークの世界的な相互運用性の範囲内にあります。さらに、モノのインターネット（たとえば、ビデオ映像を供給する監視カメラ）の登場により、このリストは、Bluetoothや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.
この多数の接続機会を活用するために、ユーザー端末にはさまざまなワイヤレスアクセスインターフェイスが装備され、拡張された接続機会が提供されます。このようにして、そのようなデバイスは、利用可能な帯域幅、バッテリー消費、ユーザープロファイルに応じたさまざまなリンク条件へのアクセス、またはさまざまなコンテンツへのアクセスなどのさまざまな基準に従って、最適なアクセスの種類を選択できるようになります。最終的に、これらの側面は、エンドユーザーが認識するQoEに貢献します。これは、ビデオコンテンツに関しては最も重要です。
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.
ただし、これらのユーザーはモバイルであり、ワイヤレステクノロジーを使用しているため、特定の瞬間の現在の最適なリンク状態が持続しないか、ユーザーが移動している間維持されない非常に動的な設定が提供されます。これらの側面は、FP7 MEDIEVAL [MEDIEVAL]などの最近完了したプロジェクトで十分に分析されています。このプロジェクトでは、ワイヤレス条件と使用可能な代替接続ポイントに関するレポートイベントが、共同ネットワークとモバイル端末のモビリティの生成に向けたビデオ要件とトラフィック最適化メカニズムと組み合わされました。管理決定。具体的には、[Fu13]では、無線信号の劣化に関するリンク情報をネットワーク内のモビリティ管理コントローラーに向けて送信した。この入力は、ユーザープロファイルおよび現在のビデオサービス要件に関する情報と組み合わされ、スケーラブルビデオレイヤーの増減をトリガーするために使用されました（進行中のリンク条件にビデオを調整します）。新しい、より優れた接続の機会が現れたときに、ビデオを段階的に調整することもできます。
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 [Corujo12]).
このようにして、ビデオ適応に関して、ICNメカニズムは、固有の複数ソースサポート機能を活用して、現在のリンクのステータスの監視を超えて、さまざまな接続の可能性（たとえば、さまざまな「インターフェース」）の可用性を利用できます。さらに、ネットワークリンクのモバイルターミナルの観点から取得した情報、およびネットワーク自体からの情報（つまり、負荷、ポリシーなど）は、そのような情報が共同最適化手順で組み合わされて、利用可能な最良の接続オプションを使用してユーザーに転送されるコンテンツ（たとえば、[Corujo12]のようなICN組み込みメカニズムによってサポートされる管理機能の利用）。
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.
実際、ICNベースのメカニズムは、大規模なマルチメディアイベント（つまり、コンサート、スポーツ）に参加するユーザーからの大量のリクエストに対してネットワークを準備し、コンテンツ、ユーザー、およびネットワークに応じてビデオを適合させるなど、新しい展開シナリオを可能にするためにさらに活用できます。要件、および動的な方法での操作機能。
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 ネットワークの現在の機能への要件（および特性）の定義とマッピングを可能にする汎用ビデオサービス（および明らかにコンテンツ）インターフェイスを開発する方法。
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 端末のビデオアプリケーションまたはある種のネットワーク管理エンティティのいずれかが動的にビデオコンテンツを適応できるようにするスケーラブルなメカニズムを定義する方法。
o how to develop the previous research items using intrinsic ICN mechanisms (i.e., naming and strategy layers);
o 固有のICNメカニズムを使用して以前の研究項目を開発する方法（つまり、命名および戦略レイヤー）。
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 コンテンツのインテリジェントな事前キャッシュを活用して、ユーザーのQoEの低下につながるストールや低品質のフェーズを防ぐ方法：これには、特に、モバイル環境での使用が含まれます。 [Crabtree13]に示されている停止。そして
o how to take advantage of the multipath opportunities over the heterogeneous wireless interfaces.
o 異種ワイヤレスインターフェイスを介してマルチパスの機会を利用する方法。
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.
異種ソースを組み合わせるための興味深い研究領域は、ネットワークコーディング[Montpetit13b]を使用することです。ネットワークコーディングでは、複数のソースを非同期で組み合わせることができます。各ソースは、他のソースと重複していないが、組み合わせてビデオストリームを取得できる情報を送信します。
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.
ただし、これにより、ビデオストリームの適切なレート適応の定義、エンコードデータの保護、エンコードデータのキャッシュ、エンコードデータの適時性、ネットワークリソースと追加のバッファリングの両方でのネットワークコーディング操作のオーバーヘッドの点で、ICNに問題が生じます。遅延など
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 research group.
ネットワークコーディングは、ユニキャスト、マルチキャスト、およびP2P設定でのバッファリングイベントの削減に有望です。 [Medard12]は、ネットワークコーディングを使用してマルチメディア通信のQoEを強化する戦略を検討しています。ネットワークコーディングは、複数のストリームに適用できますが、構成可能な消去コードと同等の単一のストリーム内にも適用できます。明らかに、研究グループの活動のトピックとして、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.
ICNは、ビデオチャンクのフェッチを場所から切り離します。つまり、オーディオチャンクは1つのネットワーク要素（キャッシュ/ストレージ/サーバー）から受信でき、ビデオチャンクは別のネットワークエレメントから受信でき、さらに別のチャンク（次のチャンク、または同じビデオストリームの別のレイヤーなど）は受信できます。 3番目の要素から来ています。これにより、同時（またはほぼ同じ）に再生する必要のあるビデオストリームのさまざまな要素の取得時間と場所に差異が生じます。そのような配信と再生の同期には、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 たとえば、単一のストリーム内では、ソースレイヤーとトランスポートレイヤーが異なる場合は、単一のストリームの連続したチャンクや、階層化スキームの複数のレイヤー。
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 window;
o ビデオクライアントで複数のソースに分散されたストリームのパケットを並べ替えるか、複数のソースからの複数のチャンクが許容可能な時間枠内に到着するようにします。
o multiple streams, such as the audio and video components of a video stream, which can be received from independent sources; and
o ビデオストリームのオーディオコンポーネントやビデオコンポーネントなど、独立したソースから受信できる複数のストリーム。そして
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.
o ライブイベントの大量配布など、複数のソースから複数の宛先への複数のストリーム。たとえば、ライブビデオストリームやビデオ会議の場合、ストリームを見ている人が同じイベントを同時に見ることができるように、ある程度の同期が必要です。
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.
これらの問題の一部は、ソーシャルビデオの消費に関連して[Montpetit13a]で対処されました。トラフィックエンジニアリングを使用したネットワークコーディングは、同期の問題の潜在的なソリューションと見なされています。 ICNに固有のその他のアプローチも考えられます。
Traffic engineering in ICN [Su14] [Chanda13] may be required to provide proper synchronization of multiple streams.
複数のストリームを適切に同期するには、ICN [Su14] [Chanda13]のトラフィックエンジニアリングが必要になる場合があります。
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.
このドキュメントでは、ICNの適応型ビデオストリーミングを提案し、潜在的な問題を特定し、ソリューションとしてCCNとDASHの組み合わせを示します。 DASHとCCNの両方の概念は、たとえば、異なるバージョンのコンテンツがセグメントで処理されるなど、いくつかの要素を共通に維持しているため、両方のテクノロジーを組み合わせると便利です。したがって、CCNを介したアダプティブストリーミングは、CCNの効率的なキャッシングと組み込みマルチキャストサポート、名前付きデータURIに基づくルーティング、組み込みマルチリンクとマルチソースサポートなどの利点を活用できます。
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.
このコンテキストでは、モバイル環境でのCASHとDASHの併用は、特に複数のネットワークインターフェイスを備えたデバイスの場合、今日のソリューションと比較して利点があります。複数のリンクを介した並列データの取得は、実際のDASHクライアントに対して透過的な帯域幅機能に応じて、利用可能なリンクを動的に切り替える可能性を提供するため、特にアダプティブマルチメディアストリーミングに役立つ機能です。
[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.
[Rainer16] Rainer、B.、Posch、D。、およびH. Hellwagner、「NDNでのプルベースの動的適応ストリーミングのパフォーマンスの調査」、IEEE Journal on Communications in Selected Areas（J-SAC）：Special Issue on Video Future Internet、Volume 34、Number 8、DOI 10.1109 / JSAC.2016.2577365、2016年8月での配布。
[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, <http://www.rfc-editor.org/info/rfc6972>.
[RFC6972] Zhang、Y。およびN. Zong、「問題の声明とピアツーピアストリーミングプロトコル（PPSP）の要件」、RFC 6972、DOI 10.17487 / RFC6972、2013年7月、<http：//www.rfc -editor.org/info/rfc6972>。
[ATIS-IIF] "ATIS: IIF, IPTV Interoperability Forum", 2015, <http://www.atis.org/iif/deliv.asp>.
[ATIS-IIF]「ATIS：IIF、IPTV Interoperability Forum」、2015年、<http://www.atis.org/iif/deliv.asp>。
[Bakker15] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-Peer Streaming Peer Protocol (PPSPP)", RFC 7574, DOI 10.17487/RFC7574, July 2015, <http://www.rfc-editor.org/info/rfc7574>.
[Bakker15] Bakker、A.、Petrocco、R。、およびV. Grishchenko、「ピアツーピアストリーミングピアプロトコル（PPSPP）」、RFC 7574、DOI 10.17487 / RFC7574、2015年7月、<http：// www。 rfc-editor.org/info/rfc7574>。
[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.
[Castro03] Castro、M.、Druschel、P.、Kermarrec、A.、Nandi、A。、および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、2003年10月。
[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.
[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。、および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 、2011年3月。
[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.
[Chanda13] Chanda、A.、Westphal、C。、およびD. Raychaudhuri、「ソフトウェア定義情報中心ネットワークにおけるコンテンツベースのトラフィックエンジニアリング」、2013 IEEE Conference on Computer Communications Workshops（INFOCOM WKSHPS）、DOI 10.1109 / INFCOMW.2013.6970717、 2013年4月。
[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.
[Corujo12] Corujo、D.、Vidal、I.、Garcia-Reinoso、J。、およびR. Aguiar、「A Named Data Networking Flexible Framework for Management Communications」、IEEE Communications Magazine、Volume 50、Issue 12、DOI 10.1109 / MCOM.2012.6384449、2012年12月。
[Crabtree13] 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.
[Crabtree13] Crabtree、B.、Stevens、T.、Allan、B.、Lederer、S.、Posch、D.、Mueller、C。、およびC. Timmerer、「制限付き/ゼロネットワークカバレッジでのビデオ適応」、CCNxCon 2013年、パロアルトリサーチセンター（PARC）、2013年9月。
[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 Information-Centric Networking, DOI 10.1145/2018584.2018598, August 2011.
[Detti11] Detti、A.、Blefari-Melazzi、N.、Salsano、S。、およびM. Pomposini、「CONET：A Content Centric Inter-Networking Architecture」、情報中心のネットワーキングに関するACM SIGCOMMワークショップの議事録、DOI 10.1145 / 2018584.2018598、2011年8月。
[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.
[Detti12] Detti、A.、Pomposini、M.、Blefari-Melazzi、N.、Salsano、S。、およびA. Bragagnini、「情報中心のネットワーキングによるセルラーネットワークのオフロード：ビデオストリーミングの場合」、2013 IEEE 14thワイヤレス、モバイル、マルチメディアネットワークの世界に関する国際シンポジウム（WoWMoM）、DOI 10.1109 / WoWMoM.2012.6263734、2012年6月。
[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, September 2013.
[Detti13] Detti、A.、Ricci、B。、およびN. Blefari-Melazzi、「Peer-to-Peer Live Adaptive Video Streaming for Information Centric Cellular Networks」、2013 IEEE 24th Annual International Symposium on Personal、Indoor、およびMobile無線通信（PIMRC）、DOI 10.1109 / PIMRC.2013.6666771、2013年9月。
[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.
[Fiat94] Fiat、A.およびM. Naor、「Broadcast Encryption」、Advance in Cryptology-CRYPTO '93 Proceedings、Lecture Notes in Computer Science、ボリューム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.
[Fu13] Fu、B.、Kunzmann、G.、Wetterwald、M.、Crujo、D。、およびR. Costa、「QoE対応のトラフィック管理、モバイルビデオ配信」、2013 IEEE International Conference on Communications Workshops（ICC） 、DOI 10.1109 / ICCW.2013.6649314、2013年6月。
[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, July 2013.
[Grandl13] Grandl、R.、Su、K。、およびC. Westphal、「適応型ビデオストリーミングとコンテンツ中心のネットワークの相互作用について」、2013 IEEE International Conference on Multimedia and Expo（ICME）、DOI 10.1109 / ICME。 2013.6607500、2013年7月。
[IETF-PPSP] IETF, "Peer to Peer Streaming Protocol (ppsp)", <https://datatracker.ietf.org/wg/ppsp/>.
[IETF-PPSP] IETF、「ピアツーピアストリーミングプロトコル（ppsp）」、<https://datatracker.ietf.org/wg/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.
[ISO-DASH] ISO、「情報技術-HTTP経由の動的適応ストリーミング（DASH）-パート1：メディアプレゼンテーションの説明とセグメント形式」、ISO / IEC 23009-1：2014、2014年5月。
[ITEC-DASH] "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>.
[ITEC-DASH]「ITEC-Dynamic Adaptive Streaming over HTTP」、情報技術研究所のDASH Research、マルチメディア通信グループ、Alpen-Adria Universitaet Klagenfurt、<http://dash.itec.aau.at>。
[Jacobson09a] 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.
[Jacobson09a] Jacobson、V.、Smetters、D.、Briggs、N.、Plass、M.、Stewart、P.、Thornton、J.、and R. Braynard、 "VoCCN：Voice-over Content-Centric Networks"、 2009年のインターネットの再構築に関するワークショップの議事録、DOI 10.1145 / 1658978.1658980、2009年12月。
[Jacobson09b] 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.
[Jacobson09b] 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、2009年12月。
[LeCallet13] 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.
[LeCallet13] Le Callet、P.、Moeller、S。、およびA. Perkis、「Quality of Experiences of Definitions of Experience」、マルチメディアシステムおよびサービスにおけるQuality of Experienceに関するヨーロッパのネットワーク、COSTアクションIC 1003、バージョン1.2 、2013年3月。
[Lederer13a] 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 2013.
[Lederer13a] Lederer、S.、Liu、Y.、Geurts、J.、Point、J.、Lederer、S.、Mueller、C.、Rainer、B.、Timmerer、C。、およびH. Hellwagner、「Dynamic CCNを介したアダプティブストリーミング：キャッシュとオーバーヘッドの分析」、2013 IEEE International Conference on Communication（ICC）、DOI 10.1109 / ICC.2013.6655116、2013年6月。
[Lederer13b] 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.
[Lederer13b] Lederer、S.、Mueller、C.、Rainer、B.、Timmerer、C。、およびH. Hellwagner、「A Content Centric NetworksにおけるHTTPを介した動的適応ストリーミングの実験的分析」、2013マルチメディアに関するIEEE国際会議およびExpo（ICME）、DOI 10.1109 / ICME.2013.6607500、2013年7月。
[Magharei07] 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.
[Magharei07] Magharei、N.、Rejaie、R。、およびY. Guo、「メッシュまたはマルチツリー：ライブP2Pストリーミングアプローチの比較研究」、IEEE INFOCOM 2007-26th IEEE International Conference on Computer Communications、DOI 10.1109 / INFCOM.2007.168、2007年5月。
[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 2012.
[Medard12] Medard、M.、Kim、M.、Parandeh-Gheibi、M.、Zeng、W。、およびM. Montpetit、「Quality of Experience for Multimedia Communications：Network Coding Strategies」、Laboratory of Electronics、Massachusetts Institute ofテクノロジー、2012年3月。
[MEDIEVAL] "MEDIEVAL: MultiMEDia transport for mobIlE Video AppLications", 2010, <http://www.ict-medieval.eu>.
[MEDIEVAL]「MEDIEVAL：モバイルビデオアプリケーション向けのMultiMEDiaトランスポート」、2010、<http://www.ict-medieval.eu>。
[Montpetit13a] 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.
[Montpetit13a] Montpetit、M.、Holtzman、H.、Chakrabarti、K。、およびM. Matijasevic、「ソーシャルビデオの消費：デバイスとネットワーク全体での同期した視聴体験」、2013 IEEE国際会議に関するコミュニケーションワークショップ（ICC）、pp。 286-290、DOI 10.1109 / ICCW.2013.6649245、2013。
[Montpetit13b] 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.
[Montpetit13b] Montpetit、M.、Westphal、C。、およびD. Trossen、「ネットワークコーディングと情報中心のネットワーキングの融合：ネイティブネットワークコーディングによる情報分散のアーキテクチャ上のケース」、新興の名前指向に関する第1回ACMワークショップの議事録モバイルネットワーキングの設計、アーキテクチャ、アルゴリズム、およびアプリケーション、DOI 10.1145 / 2248361.2248370、2013年6月。
[Mueller12] 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.
[Mueller12] 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、2012年11月。
[NETINF] "NetInf: Network of Information", <http://www.netinf.org>.
SHNETINFSH "Netinf：Network of Information"、<http：//vvv.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.
[Posch13] Posch、D.、Hellwagner、H。、およびP. Schartner、「動的適応暗号化コンテンツチャンクに基づくオンデマンドビデオストリーミング」、第8回セキュアネットワークプロトコルに関する国際ワークショップ（NPSec '13）の議事録、DOI 10.1109 / ICNP.2013.6733673、2013年10月。
[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, <http://www.rfc-editor.org/info/rfc7476>.
[RFC7476] Pentikousis、K.、Ed。、Ohlman、B.、Corujo、D.、Boggia、G.、Tyson、G.、Davies、E.、Molinaro、A.、and S. Eum、 "Information-Centricネットワーキング：ベースラインシナリオ」、RFC 7476、DOI 10.17487 / RFC7476、2015年3月、<http://www.rfc-editor.org/info/rfc7476>。
[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, <http://www.rfc-editor.org/info/rfc7846>.
[RFC7846] Cruz、R.、Nunes、M.、Xia、J.、Huang、R.、Ed。、Taveira、J。、およびD. Lingli、「ピアツーピアストリーミングトラッカープロトコル（PPSTP）」、 RFC 7846、DOI 10.17487 / RFC7846、2016年5月、<http://www.rfc-editor.org/info/rfc7846>。
[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.
[Su14] Su、K。およびC. Westphal、「トラフィックエンジニアリングのための情報中心ネットワークの利点について」、2014年IEEE通信国際会議（ICC）、DOI 10.1109 / ICC.2014.6883810、2014年6月。
Acknowledgments
謝辞
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 and liability.
この作品は、SocialSensor（FP7-ICT-287975）プロジェクトのコンテキストでヨーロッパ共同体によって部分的にサポートされ、AAUのLakeside Labs研究クラスターで部分的に実行されました。 SocialSensorは、欧州共同体の第7フレームワークプログラムから研究資金を受け取ります。このドキュメントの作業は、FP7 / NICT EU-JAPAN GreenICNプロジェクト<http://www.greenicn.org>のコンテキストでも部分的に実行されました。これとは別に、欧州委員会はこの文書の内容に対して責任を負いません。このドキュメントの情報は現状のまま提供されており、その情報が特定の目的に適合していることを保証または保証するものではありません。そのユーザーは、その唯一のリスクと責任において情報を使用します。
Authors' Addresses
著者のアドレス
Cedric Westphal (editor) Huawei
セドリック・ウェストファル（編者）ファーウェイ
Email: Cedric.Westphal@huawei.com
Stefan Lederer Alpen-Adria University Klagenfurt
Stefan Lederer Alpen-Adria Universityクラーゲンフルト
Email: stefan.lederer@itec.aau.at
Daniel Posch Alpen-Adria University Klagenfurt
ダニエルポッシュアルペンアドリア大学クラーゲンフルト
Email: daniel.posch@itec.aau.at
Christian Timmerer Alpen-Adria University Klagenfurt
クリスチャンティメラーアルペンアドリア大学クラーゲンフルト
Email: christian.timmerer@itec.aau.at
Aytac Azgin Huawei
アイタックアズギンファーウェイ
Email: aytac.azgin@huawei.com
Will (Shucheng) Liu Huawei
will（Shu成）l IU hu A
Email: liushucheng@huawei.com
Christopher Mueller BitMovin
クリストファー・ミューラーBitMovin
Email: christopher.mueller@bitmovin.net
Andrea Detti University of Rome Tor Vergata
アンドレアデッティローマ大学Tor Vergata
Email: andrea.detti@uniroma2.it Daniel Corujo Instituto de Telecomunicacoes Aveiro
メール：andrea.detti@uniroma2.it Daniel Corujo Instituto de Telecomunicacoes Aveiro
Email: dcorujo@av.it.pt
Jianping Wang City University of Hong Kong
香港建平王市立大学
Email: jianwang@cityu.edu.hk
Marie-Jose Montpetit MIT
マリーホセモンプティMIT
Email: marie@mjmontpetit.com
Niall Murray Athlone Institute of Technology
ニアルマレーアスローン工科大学
Email: nmurray@research.ait.ie