NDN 方式を活用した高品質なコンテンツ配信に向けた諸検討

(1)

平成 27 年度修士論文

NDN 方式を活用した高品質なコンテンツ配信に向けた諸検討

早稲田大学基幹理工学研究科情報理工学専攻 5113B093-4

武藤健史指導甲藤二郎教授

2015 年 2 月 2 日

指導教授印受付印

(2)

第1章序論 1.1. はじめに

現在のインターネットではモバイルビデオの需要が増加しており、未来の無線ネットワークの課題となっている。モバイルビデオコンテンツは他のモバイルデータよりもはるかに高いビットートを有しているため、2018年までにはモバイルデータトラフィックの69%以上を占めることがシスコシステムズにより発表された[1]。さらに、ユーザが動画を閲覧する時にスタートアップ時間が 2 秒を超えるとユーザは動画の閲覧を諦めることや、閲覧時にリバッファリングの時間が長ければ長いほど動画の閲覧をあきらめてしまうということも AKAMAI から発表されている[2]。

交通機関を利用した先回りコンテンツ配信システム[3]は効率的な無線のリソースを用いてロバストなコンテンツ配信を提供するために提案されている。このシステムによって特に列車の運行中に車内のユーザが効率良く高画質な動画コンテンツを再生できることが可能となる。このシステムは全ての駅や列車内にNDN機能を備えたサーバーを必要とする。メカニズムとしては列車が駅に到着する前にユーザが要求したコンテンツを駅のサーバーに事前にキャッシュをし、

列車の停車中にそのコンテンツを列車内のサーバーにキャッシュをする。これによって車内のユーザは列車が移動中でもスムーズで連続的な動画の再生をすることが可能となる。

本稿ではこの先回りコンテンツ配信システムを新世代ネットワークアーキテクチャーである

NDN(Named Data Networking)上で実現をするため、DASH-NDN-JSと呼ばれるブラウザベ

ースの実装を提案する。この方式での性能評価を行い、マルチユーザにおいて擬似的なフィールド実験を行った。この方式を用いることで先回りコンテンツ配信システムの全自動化が可能となったことに結論付けている。

(6)

1.2. 本論文の構成

第2章では、TCPの輻輳制御方式について述べる。

第3章では、NDN(Named Data Networking)について述べる。

第4章では、ストリーミングについて述べる。

第5章では、交通機関を利用した先回りコンテンツ配信システムについて述べる。

第6章では、DASH-NDN-JSについて述べる。

第7章では、NDN方式を活用した先回りコンテンツ配信アプリケーションについて述べる。

第8章では、本実験・実験結果について述べる。

第9章では、まとめと今後の展開について述べる。

(7)

第2章 TCP の輻輳制御方式

本章ではTCP(Transmission Control Protocol)について説明をする。

現在は多くの輻輳制御方式が利用され、以下には Loss-based 手法で多くの OS に搭載される TCP-Reno、Delay-based手法のTCP であるTCP-Vegas、Loss-based手法でLinuxが現在の標準のTCPとしているCUBIC-TCPについて述べる。

2.1. TCP-Reno

TCP-Reno[4]はスロースタートフェーズと輻輳回避フェーズの2つのフェーズから構成され、

応答確認を受信するたびに輻輳ウィンドウサイズを増加させていく。スロースタート閾値(ssth) と輻輳ウィンドウサイズ(cwnd)は具体的に式(2.1)、(2.2)のように変化する。

𝑐𝑤𝑛𝑑 = 𝑐𝑤𝑛𝑑 + 1 𝑐𝑤𝑛𝑑 < 𝑠𝑠𝑡ℎ (2.1)

𝑐𝑤𝑛𝑑 = 𝑐𝑤𝑛𝑑 + 1

𝑐𝑤𝑛𝑑 𝑐𝑤𝑛𝑑 > 𝑠𝑠𝑡ℎ (2.2) 式(2.1)から、スロースタート時にはACKを受信するたびにcwndが指数的に増加し、式(2.2) から、輻輳回避フェーズに移行するとcwndが線形的に増加していくことが分かる。また、再送タイムアウトが発生するとcwndとssthは以下の式(2.3)のように設定される。

{𝑠𝑠𝑡ℎ =

𝑐𝑤𝑛𝑑𝑙𝑎𝑠𝑡_𝑚𝑎𝑥

2 𝑐𝑤𝑛𝑑 = 1

(2.3)

𝑐𝑤𝑛𝑑_{𝑙𝑎𝑠𝑡_𝑚𝑎𝑥} ∶ パケットロスが発生したときの輻輳ウィンドウサイズ

このように輻輳ウィンドウサイズは1となってしまい、ssthの値に到達するまでは式(2.1)に示すように指数的に増加し、輻輳回避フェーズに移行されると式(2.2)に示すように線形的に増加する。

また、パケットロスや重複応答確認による高速再送制御が行われた場合、cwnd と ssth は以下の式(2.4)のように設定される。

{

𝑠𝑠𝑡ℎ =𝑐𝑤𝑛𝑑𝑙𝑎𝑠𝑡_𝑚𝑎𝑥

2 𝑐𝑤𝑛𝑑 =𝑐𝑤𝑛𝑑_{𝑙𝑎𝑠𝑡_𝑚𝑎𝑥}

2

(2.4)

図2.1のように輻輳ウィンドウサイズがスロースタート閾値に落とされ、スロースタートフェーズではなく輻輳回避フェーズに移行され、式(2.2)に示すように線形的に増加する。

(8)

図 2.1 TCP-Renoにおけるウィンドウ変化

2.2. TCP-Vegas

TCP-Vegas[5]はRTTの増減をもとに制御を行う、Delay-Based手法の輻輳制御方式である。

まず式(2.5)に示すようにRTTを計測しながらActual ThroughputとExpected Throughputの２つのスループットの比較を行い、バッファ内の滞留パケット数を算出する。現在の輻輳ウィンドウサイズを cwnd、計測した最小のラウンドトリップタイムを RTTmin、現在のラウンドトリップタイムをRTTとする。

Expected Throughput

:

^{𝑐𝑤𝑛𝑑}

𝑅𝑇𝑇_𝑚𝑖𝑛

Actual Throughput: ^{𝑐𝑤𝑛𝑑} 𝑅𝑇𝑇

𝑑𝑖𝑓𝑓 = ( 𝑐𝑤𝑛𝑑

𝑅𝑇𝑇_𝑚𝑖𝑛−𝑐𝑤𝑛𝑑

𝑅𝑇𝑇) (2.5)

式(2.1)で算出したバッファ内滞留パケット数を基に 3 つの条件において輻輳ウィンドウサイズを変化させていく。α、βを定数とし、そのアルゴリズムを式(2.6)に示す

𝑐𝑤𝑛𝑑 = {

𝑐𝑤𝑛𝑑 + 1 𝑑𝑖𝑓𝑓 < 𝛼 𝑐𝑤𝑛𝑑 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒 𝑐𝑤𝑛𝑑 − 1 𝑑𝑖𝑓𝑓 > 𝛽

(2.6)

スロースタート輻輳回避輻輳回避輻輳回避輻輳回避

：輻輳ウィンドウ

：スロースタート閾値時間

(9)

diffの値が下限値よりも低かった場合(Expected Throughput > Actual Throughput)にはネットワーク帯域が空いていると判断して輻輳ウィンドウサイズを 1増加させる。反対にdiffの値が上限値よりも高かった場合(Expected Throughput < Actual Throughput)にはネットワーク帯域が混雑してきたと判断して輻輳ウィンドウサイズを1減少させる。また、diffの値が上限値と下限値の間の値の時(Expected Throughput = Actual Throughput)はネットワークが安定していると見なして転送速度を維持する。また、パケットロス時には式(2.7)のように輻輳ウィンドウサイズを減少させる。

𝑐𝑤𝑛𝑑 = 𝑐𝑤𝑛𝑑 ∗ 0.75 (2.7)

図2.2に示すようにTCP-Vegasはバッファ内で輻輳を制御していることが分かる。

図 2.2 TCP-Vegasのウィンドウサイズの変化

2.3. CUBIC-TCP

CUBIC-TCP[6]はBIC(Binary Increase Congestion Control)を改良した輻輳制御方式で、最後にパケットロスが発生した時からの超過時間を利用して輻輳制御が行われる。式(2.8)のように輻輳ウィンドウサイズを変化させていく。

𝐾 = √𝑊_𝑚𝑎𝑥𝛽 𝐶

3 𝑐𝑤𝑛𝑑 = 𝐶(𝑡 − 𝐾)³+ 𝑊_𝑚𝑎𝑥

(2.8) Congestion Window

diff>β α<diff<β diff<α Time

Buffer

(10)

C CUBICパラメータ

t 前回のパケットロス時からの経過時間

K 現在の輻輳ウィンドウサイズがWmaxまで増加するにかかる時間 β パケットロス時の輻輳ウィンドウ減少率

また、パケットロスが発生した場合、式(2.9)のように輻輳ウィンドウサイズを減少させる。

パケットロス時のウィンドウサイズが前回のロス時のウィンドウサイズよりも小さい場合は cwndlast_maxを式(2.10)のように変化させる。

𝑐𝑤𝑛𝑑 = 𝑐𝑤𝑛𝑑 ∗ (1 − 𝛽) (2.9)

𝑐𝑤𝑛𝑑_{𝑙𝑎𝑠𝑡_𝑚𝑎𝑥} = 𝑐𝑤𝑛𝑑 ∗2 − 𝛽

2 (2.10)

CUBIC-TCPにおける輻輳ウィンドウサイズの変化を図2.3に示す。

図 2.3 CUBIC-TCP 輻輳ウィンドウサイズの変化

パケットロスによりcwnd<Wmax(Steady State Behavior)となる場合には輻輳ウィンドウサイズを前回のパケットロス時の Wmaxまで素早く回復をさせる。Wmaxとなった時には増加が緩やかになり、cwnd>Wmax(Max Probing)なった時には輻輳ウィンドウサイズをまた急激に増加させている。

(11)

第3章 Named Data Networking (NDN)

現在のインターネットは、ユーザがコンテンツ要求を行う時にはネットワークのアドレス(i.e.

URLs)を用いてコンテンツの場所を特定するhost-to-hostの通信に基づいている。しかし、ユー

ザの多くはコンテンツの格納場所よりもコンテンツ自体のことを重視してコンテンツを要求している。

この問題を解決するためにVan JacobsonよりContent Centric Network(CCN)[7]が提案された。このネットワークパラダイムの主概要としてはネットワーク全体でコンテンツの名前に基づいたルーティングとコンテンツのキャッシングを提供することである。データ指向型ネットワークであり、位置依存型アドレス(IPアドレス)ではなくコンテンツの名前で通信を行うことによってはネットワークのトポロジーを知らなくてもコンテンツの要求をすることが可能となる。

従って、コンテンツの名前によりコンテンツの永続性と可用性を提供し、ネットワーク内のキャッシュメカニズムによりグローバル配信とend-to-end通信を不要とするため低遅延を提供することが可能となる。Named Data Networking (NDN) [8]はCCNをベースとして発展させたものであり、次世代のインターネットアーキテクチャーの候補として開発が進められている。

3.1. 基本的なデータ交換

NDN上でのデータ配信においてはInterestとData(Content Object)という2つのメッセージタイプの交換によって行われる。InterestメッセージはコンテンツのChunkの名前を指定することによってデータを要求するために使われる。また、同じプリフィックスを持ったコンテンツの中でユーザが要求したものに最も適したデータを制限するために、名前のプリフィックスが含まれている。また、Content Objectメッセージはデータを供給するために使用される。

図3.1に示すようにContent Objectには名前、発行者、データペイロード、暗号化シグネチャ、

発行者の識別情報など様々な情報が含まれて構成されている。

図 3.1 Interest/Content Objectメッセージの構成

(12)

NDN の通信においては、データを要求するクライアント(Consumer)は全てのコネクション

(face)に向けてInterestメッセージをブロードキャストし、このInterestに相当するコンテンツ

を所持しているノード(Pubisher)は必ず最大で一つのContent Objectメッセージで返答しなくてはならない。Interest を満たすためには Interest メッセージに含まれているプリフィックス

とContent Objectメッセージに含まれるコンテンツの名前のプリフィックスと一致しなければ

ならない。

3.2. NDN ノードの構成

NDNのノードにはネットワーク内のキャッシングとループフリー転送を提供するために3つの主要なデータ構造が含まれている。

3.2.1. Content Store (buffer memory)

Content Store はコンテンツのキャッシングに用いるメモリで異なるキャッシングアルゴリ

ズムを持つIPルータに類似している。各パケットはConsumerに有用である可能性があるので、

同じコンテンツを再利用する可能性を最大化するためにLRU (Least Recently Used)または、

LFU(Least Frequently Used)アルゴリズムが実装されている。

3.2.2. FIB (Forwarding Information Base)

FIBはInterest パケットをコンテンツを所持しているノードに転送するために用いられる。

これによって接続している全てのノードにInterestをブロードキャストすることが可能となる。

3.2.3. PIT (Pending Interest Table)

PITは上流に転送されたInterestを監視し、そのInterestに対するContent Objectメッセー

ジをConsumerへ返送するために用いられる。各PITのエントリは転送されたInterestに適す

るContent Objectメッセージが下流に転送された場合に削除される。

3.2.4. 仕様

Consumerから送信されたInterestがあるfaceに到達した時、コンテンツ名の最長一致検索

が行われる。Interestに適するデータがContent Storeに存在した場合には同じfaceを介して

Content Object Messageを返し、Interestが満たされたと判断を行う為、そのInterestは廃棄

される。反対にInterestに相当するデータがContent Storeに存在しない場合かつFIBエント

リにInterest 名と一致するプリフィックスが存在した場合には、図3.2 に示すように該当する

(13)

ための経路表としてPITエントリが更新される。また、Interestがあるface到達した時にPIT エントリに完全一致する名前があった場合、他のユーザが同じコンテンツを要求していると判断をし、faceとInterest名の情報がPITに更新されInterestは廃棄される。そのInterestを満

たすContent Objectが到達した場合には両方のfaceに向けて転送される。NDNはネットワー

ク内キャッシングを提供しているため、図3.3に示すようにContent Objetメッセージがあるノードを通過すると、Content Store にキャッシュされる仕組みとなっている。なお、送信した

Interestを満たすContent Objectがネットワーク上に存在しない場合にはInterestは廃棄され

る。

図 3.2 Interestの送信の各ノードにおけるFIB,PIT,CSの動作

Content Store

Name Data

- -

Publisher 1

Publisher 2 Consumer

PIT

Name Requested

Face /video_1/video1.m4s 0

FIB

Name Face

/video_1/ 1

/tes ng/ 2

Face 1

Face 2

Face 0 (2)

(3) (4)

Content Store

Name Data

- -

PIT

Face FIB

Name Face

/tes ng/ 3

Content Store

Name Data

- -

PIT

FIB

Name Face

/video_1 4

Content Store

Name Data

- -

PIT

FIB

Name Face

/video_1 5

Interest Message (1) ~ (4)

Face 4 Face 5

Face 3

(14)

図 3.3 Content Objectメッセージ受信時のFIB, PIT, CSの動作

3.3. NDN アプリケーション

NDNの性能評価を行うためにはいくつかのアプリケーションが存在する。

3.3.1. NDNx / CCNx

CCNx[9]はPalo Alto Research Center(PARC)によって開発されたCCNにおける新しいアプ

ローチを開発し、評価するためのオープンソースプロジェクトである。現在のIPベースのネットワークのオーバーレイとして動作し、TCPとUDPの両方をサポートしている。

NDNx[10]はNDNプロジェクトで開発されているCCNxのバージョン0.7.2のフォーク版であ

る。両方のソフトウェアは互換性があるが、NDNxはCCNxのロードマップやリリースタイムラインとは異なる場合があり、新機能、修正、言語サポートなどを追加する予定として開発が進められている。

3.3.2. NDN-TLV

近年、NDNプロジェクトはNDNパケットをType-Length-Value(TLV)フォーマットとしてエンコードを行う方針を示した。Type とは表 3.1 に示すようにパケットの種類を定義し、

Content Store

Name Data

/video_1/video1.m4s …

Consumer

PIT

Face FIB

Name Face

/video_1/ 1

/tes ng/ 2

Face 1

Face 2 Face 0

(7) (6) (5)

Content Store

Name Data

/video_1/video1.m4s … PIT

Face FIB

Name Face

/video_1 4

Content Store

Name Data

/video_1/video1.m4s … PIT

Face FIB

Name Face

/video_1 5

Face 4 Face 5

(8)

Publisher 1

Publisher 2

Content Store

Name Data

- -

PIT

Face FIB

Name Face

/tes ng/ 3

Face 3

Content Object Message (5) ~ (8)

(15)

ドの長さを示し、Valueはペイロードそのものを示している。NDNxはTLVフォーマットとは互換性がないため、このエンコード形式のNDNパケットを対応させるためにはNDNx-TLV[11]

が必要とされる。

表 3.1 Type Valueの割り当て[12]

Type

Assigned value (decimal)

Assigned value (hexadecimal) Packet types

Interest 5 0x05

Data 6 0x06

Common fields

Name 7 0x07

NameComponent 8 0x08

ImplicitSha256DigestComponent 1 0x01 Interest packet

Selectors 9 0x09

Nonce 10 0x0a

Scope 11 0x0b

InterestLifetime 12 0x0c

Interest/Selectors

MinSuffixComponents 13 0x0d

MaxSuffixComponents 14 0x0e

PublisherPublicKeyLocator 15 0x0f

Exclude 16 0x10

ChildSelector 17 0x11

MustBeFresh 18 0x12

Any 19 0x13

Data packet

MetaInfo 20 0x14

Content 21 0x15

SignatureInfo 22 0x16

SignatureValue 23 0x17

(16)

Data/MetaInfo

ContentType 24 0x18

FreshnessPeriod 25 0x19

FinalBlockId 26 0x1a

Data/Signature

SignatureType 27 0x1b

KeyLocator 28 0x1c

KeyDigest 29 0x1d

3.3.3. NDN-JS

NDN-JS[13]はNDN初のJavascriptベースの実装であり、Interest/Content Object交換によるデータ転送を現代のウェブブラウザ(Google Chrome, Safari, Firefox, etc.)で可能としたものである。ウェブブラウザで動作するため、JavascriptとHTML5をサポートしていれば携帯端末でもNDNプロトコルの動作を行うことが可能である。さらにNDNxのルーティング、フォワーディング、通信方式との互換性があり、NDN-JS のクライアントと NDN ルータは

WebSocket proxy[14]を介すことでNDNプロトコルの評価をすることもできる。このアプリケ

ーションにより、ネイティブアプリケーションのインストールや手動のコンフィグレーションが不要となるため、容易にモバイルアプリケーションを開発することが可能となる。

3.3.3.1. NDN-JSを用いたコンテンツダウンロード

NDN-JS を用いて NDN ルータのレポジトリに格納されているコンテンツを

Interest/Content Objectメッセージによって取得する方法を以下に完結に述べる。図3.4に示

すように NDN ルータからコンテンツをダウンロードするためには WebSocket Proxy Server を介す必要がある。ブラウザから送られたInterestメッセージはWebSocketフレームとしてカプセル化され、WS Proxy ServerにおいてNDNパケットを抽出しNDNルータへと転送される。

Interestを満たすデータが存在した場合にはContent ObjectメッセージをNDNパケットとし

てWS Proxy Serverに転送され、そこでWebSocketフレームとしてカプセル化を行い、ブラウ

ザへと転送する仕組みとなっている。なお、NDNルータ間でのInterest/Content Objectメッセージの転送の仕組みは図3.2、図3.3に示す通りである。NDN-JSから送信されるNDNパケットはTLVフォーマットとなっているため、NDN RouterはNDNx-TLVを持いる必要がある。

(17)

図 3.4 WebSocket Proxyを介したNDNノードへのコネクション

動画ファイル(elephantsdream720p.mp4)のデータ転送を行う場合、以下のような手順となる。

1. NDNルータの設定

2. WebSocket Proxy Serverの設定

3. NDN-JSのコード

NDN-JS Node.js NDNx-TLV

WebSocket Proxy

Consumer NDN Router

NDN over WebSocket

NDN over TCP or UDP 192.168.100.10

192.168.100.20

ndn-tlv // ndn-tlvの起動 ndnr & // ndnレポジトリの作成

ndnputfile ndn:/elephantsdream720p.mp4 elephantsdream720p.mp4 // ndn レポジトリの中にコンテンツ名”ndn:/任意の名前”として動画ファイルを格納

node wsproxy-tcp.js –c 192.168.100.20 // (ndn-js/wsproxy/wsproxy-tcp.js) options

['-c' , ホスト名またはNDNルータのIPアドレス']

['-n' , NDNルータのポート番号(デフォルト：6363)]

['-p' , WebSocket Proxy Serverのポート番号(デフォルト：9696)]

['-m' , 最大クライアント数] ['-L' , ログレベル]

(18)

図3.5に示すように、ブラウザ上でコンテンツ名を入力することによってそのInterestメッ

セージをWebSocket Proxy Serverへ送信し、NDN Routerへ転送することによって、データの

取得が可能となる。ブラウザ上で動作するため、モバイル端末でもNDN上でデータの取得を行うことができる。

図 3.5 NDN-JSを用いたファイル転送の実行例

Express Interest Receive Content Object

<html>

<head>

//WebSocket Proxy Serverへfaceのコネクションを確立 hostip = "192.168.100.10";

var face = new Face({port:9696,host:hostip});

//Content Objectメッセージが返ってきた時の処理 function onData(interest, data) {

if(data.signedInfo.finalBlockID!=null){

document.getElementById('content').innerHTML = "Final Block Received";

document.getElementById('content').innerHTML = "Data Length: " + data.content.length;

} }

//Timeoutの処理：再送 (デフォルトtimeout=4s) function onTimeout(interest){

face.expressInterest(interest, onData, onTimeout);

}

//Interestの送信 function run() {

face.expressInterest(new Name(document.getElementById('interest').value), onData, onTimeout);

} </script>

</head>

<body>

<form>

Please Enter an Interest:<br/>

</form>

<button id="send_interest" onclick="run()">Fetch Content</button>

<p id="content">Content: <br/></p>

</body>

</html>

(19)

第4章ストリーミング

インターネット上での動画配信において最も簡単なアプローチはファイルダウンロードである。これはTCPなどを用いてネットワーク上の品質を保証することができるが、いくつかの欠点が存在する。動画は非常に大きいファイルであるため、ダウンロードに時間がかかり、また大容量の収納スペースを必要とする。さらに、動画全体のダウンロードが完了しなければ動画を再生することができないといった欠点もある。これらの問題を克服するのがビデオストリーミングであり、様々な機能を提供する。基本的な考え方としては動画を分割し、これらを連続して送信を行い、受信側が受信した部分からデコードをし始め、動画全体が届くのを待たずに部分的に再生を行うことができる方法である。ビデオストリーミングは動画の同時配信と再生を可能にする。また、再生までの遅延が短く、任意の時点でクライアントに格納されるのは動画のわずかな部分であるため、大容量の格納スペースを必要としない。

4.1. ビデオストリーミングにおける問題点[15]

インターネット上では帯域、遅延ジッタやパケット廃棄に関しての保証がないため、ストリーミングは困難である。そのため、ビデオストリーミングはこの 3 つのパラメータと対応すると共に、インターネット上で高品質な映像を確実に提供するシステムを設計することが必要である。

4.1.1. 帯域

インターネット上における2点間の帯域幅は一般的に不明であり、時間的に変化する。送信側が利用可能な帯域幅よりも早く送信した場合、輻輳が起こり、パケットが失われ、映像の品質が低下してしまう。また、その逆が起こると映像品質が最適なものとはならない。帯域幅の問題を克服するためには、利用可能な帯域幅を推定し、送信されるビデオのビットレートをそれに一致させることである。これを克服するためにTCPにより輻輳制御が行われている。TCP のレート制御は安定性と拡張性を実証し、配信の保証を提供、また大量のパケットロスを排除する。しかしストリーミングでは持続的な再送信によって長い配信時間を有してしまい、TCP の”加法増加・乗法減少”はストリーミングメディアの配信に適していないと言われている。反対

にUDP(User Datagram Protocol)はベストエフォート型配信サービスであるため、輻輳制御が

行われない。このため、TCP との公平性を実現することを目指したレート制御方式である TFRC(TCP Friendly Rate Control)が提案されている。

(20)

4.1.2. 遅延ジッタ

エンドツーエンド遅延はパケットごとに変動する。このエンドツーエンド遅延の変動を遅延ジッタと呼ぶ。受信側は受信、デコード、再生の動作を一定速度でやる必要があり、遅延ジッタによるフレームの遅延は構築されたビデオに問題を生成してしまうため、遅延ジッタは問題である。この問題は図4.1に示すように通常受信側で再生バッファを含むことによって解決される。

図 4.1 Effect of playout buffer on reducing the number of late packets([15]より)

図4.1より再生バッファによってパケットロスなどを引き起こすこともあるが、バッファリングによって再生までの時間を延ばしてパケットの遅延を排除していることが分かる。

4.1.3. パケット廃棄

パケット廃棄(ロス)には様々な種類があり、これは特定のネットワークに応じて発生する。

有線の環境でパケットロスに影響された場合、そのパケット全体が失われてしまう。無線環境においてのパケットロスはビットエラーやバーストエラーによって引き起こる。パケットロスは構築されたビデオの品質に多大なる影響を与える可能性がある。これを対処するために前方誤り訂正(FEC)、再送、error concealmentやerror-resilient video codingなどのエラー制御が提案されている。

4.2. RTP(Real Time Protocol)と RTCP(Real Time Control Protocol)

UDP では上記の3 つのパラメータを解決することができないため、上位層の RTP、RTCP Time

Packet Number Playout Delay

Packet Transmission

Playout Loss

Buffering

Packet Reception

Delay

(21)

RTCPは図4.2に示すように、リアルタイムアプリケーション特有の層に実装されている。

アプリケーション層ビデオオーディオ

アダプテーション RTP/RTCP トランスポート層 UDP or TCP

ネットワーク層 IP

リンク・物理層各種ネットワーク

図 4.2アダプテーション層の様子([16]より)

4.2.1. RTP(Real Time Protocol)

UDPは品質を保証しないプロトコルであるため、パケット損失やパケットの順序が入れ替わってしまう可能性がある。そのため、音声やデータをストリーミングするためにはRTPというデータ伝送プロトコルが用いられる。具体的に説明すると、ストリーミングにおいて送信されたパケットは受信側には一定の時間間隔では届かず、到着時間の揺らぎ(ジッタ)が生じてしまう。

これによってパケットが到着する順番が乱れてしまう可能性がある。片方向通信であれば大容量のバッファにデータを滞留しバッファリング遅延によって順序入れ替わりの問題は解決できるが、双方向通信のように小容量のバッファしか用いられなく、バッファリング時間が十分に大きくない場合は解決できない。このため図4.3に示すRTPタイムスタンプが用いられ、メディア内同期(単一メディアの同期再生)が行われる。また、パケットごとにシーケンス番号を与えることで同じタイムスタンプを持つデータの順序を整理することができ、パケット廃棄を検出することができる。

V=2 P X

CSRC カウン

ト

M パケットタイプシーケンスナンバー

タイムスタンプ SSRC識別子 CSRC識別子ペイロードフォーマット拡張

データ

図 4.3 RTPヘッダの構造([16]より)

(22)

4.2.2. RTCP(Real Time Control Protocol)

RTPと共につかわれ、データのフロー制御および送信者と受信者の情報を提供する。RTCP はメディア接続時に、送信バイト数、送信パケット数、パケットロス数、ジッタ、フィードバック情報、RTTといった統計情報を集める。またRTCPには送信者レポートパケット、受信者レポートパケット、送信元記述パケット、退去メッセージパケット、アプリケーション定義パケットなど様々なパケットの種類がある。図4.4にヘッダの構造、図4.5に送信者レポートバケットの構造、また図4.6に受信者レポートパケットの構造を示す。

v=2 P RC PT=SR=200 パケット長

送信元SSRC識別子図 4.4 ヘッダの構造([16]より)

NTPタイムスタンプ(MSB) NTPタイムスタンプ(LSB)

RTPタイムスタンプ送出パケット数

送出バイト数

図 4.5 送信者レポートバケットの構造([16]より)

SSRC識別子 #n

瞬時廃棄率累積廃棄パケット数シーケンスナンバーの最大値

ジッタ遅延

最新のSR受信時のNTPタイムスタンプ(LSR) LSRから現在までの遅延(DLSR)

図 4.6 受信者レポートバケットの構造([16]より)

図4.5よりSender Reportには送信者からのストリームに関する情報が格納され、図4.6か

らはReceiver Reportにはジッタ遅延など、受信者での受信品質に関する情報が格納されている

ことが分かる。この2つのレポートパケットを用いることによって、送信者は受信者での受信品質(パケットロス、RTTなど)を知ることができる。RTP・RTCPを用いたストリーミングのメカニズムは図4.7のようになる。

(23)

図 4.7 RTP/ RTCPの使い方([16]より)

このようにメディアパケット(RTPパケット)を送信する度に制御パケット(RTCP-SR、

RTCP-RR)を送信することで、パケットロスが発生した場合など受信者がシーケンス番号を参照することによってパケットロスを検出することができる。また、送信者がRTCP-SRを送った時間を記憶し、受信者がRTCP-SRを受け取ってからRTCP-RRを送るまでの時間を計算して

RTCP-RRに記述することによって、送信者はRTCP-SRを送ってからRTCP-RRを受けとるの

にかかった時間(a)からRTCP-RRに記述されている受信者が送信までにかかった時間(b)の差分をとることによってRTTを計測することができる。

また、RTCPはメディア間同期(複数メデイアの同期)を行う。音声と動画はそれぞれRTP タイムスタンプを用いることによってメディア内同期を行うが、音声と動画のメディア間でのずれが生じてしまう可能性がある。これを防ぐために共通のNTP軸において図4.5に示すNTP タイムスタンプを利用することによって適切なフロー制御を実現している。

4.3. RTSP(Real Time Streaming Protocol)

リアルタイムにストリーミングを制御する標準化されたプロトコルである。オーディオや映像などを含むマルチメディアデータを格納するサーバーを遠隔操作するためのプロトコルであり、停止、再開、終了などの操作ができるといった拡張性を持っている。図4.8にRTSP method、

図4.9にそのmethodを用いたServer-Client間の操作を示す。

メソッド方向要求条件内容ロス

RTCP-SR

RTCP-RR

(a) (b)

送信者受信者

RTP パケット

(24)

DESCRIBE C→S 推奨セッション情報の取得

ANNOUNCE C→S

S→C

オプショナル C→S:クライアントからのセッション情報の通知 S→C:セッション情報の更新

GET_PARAMETER C→S

S→C

オプショナルセッションパラメータの取得

OPTIONS C→S

S→C

必須オプション機能のチェック

PAUSE C→S 推奨メディア転送の中断

PLAY C→S 必須メディア転送の開始、再開

RECORD C→S オプショナルメディア情報の記録

REDIRECT S→C オプショナルリダイレクション

SETUP C→S 必須セッションの初期化

SET_PARAMETER C→S

S→C

オプショナルセッションパラメータの設定

TEARDOWN C→S 必須セッションの終了

図 4.8 RTSP Method([16]より)

図 4.9 RTSPによるセッションの開始(右)と停止・再開・終了([16]より) OK

Server Client Server Client DESCRIBE PAUSE

OK OK SETUP

OK 準備完了 PLAY

OK TEARDOWN

開始ストリーミング

ストリーミング STOP

終了再開停止

(25)

図4.8を参照すると、クライアントがセッションの情報を取得し、セッションの初期化を行い、メディア転送の開始することで、ストリーミングが開始される。また、停止・再開・セッションの終了はクライアントが要求することによって可能となる。

4.4. HTTP Live Streaming

HTTP Live StreamingはAppleによって提案され、WebサーバーからHTTPを用いてビデ

オ・オーディオをライブ配信し、iPhone、iPadなど主にiOSデバイスでの再生を想定している。

また、ライブ放送、オンデマンド配信の両方に対応しているストリーミング技術である。手順としては、H.264とAACでエンコードを行い、MPEG-2トランスポートストリームで多重化する。これはさらにセグメンタにより小さなセグメントファイル(.ts)に分割され、メディアファイルのリストを含むindexファイル(.m3u8)を生成する。クライアントは始めにこのindexファイルを取得し、そこに記載されたセグメントを取得することによって動画再生が可能となる。ライブ配信時は index ファイルが随時更新され、クライアントは新たに追加されるセグメントの取得を継続する。図4.10にHTTP Live Streamingのストリーミング構成を示す。

図 4.10 HTTP Live Streamingの設定([18]より)

また、HTTP Live Streamingはサーバーコンポーネント、ディストリビューションコンポー

ネント、クライアントソフトウェアの3つのパートから構成される。

(26)

4.4.1. サーバーコンポーネント

サーバーではメディアをエンコードし、エンコードされたメディアを分割、またそれらをファイルとして保存する。図4.10に記載されているメディアエンコーダはマルチメディアをデバイスから取り込み、メディアをクライアント側で設定されている形式でエンコード行い、トランスポート用にカプセル化する。エンコーダはローカルネットワークを介して、エンコードされたメディアをMPEG-2トランスポートストリームでストリームセグメンタに配信をする。ストリームセグメンタは、配信されたトランスポートストリームを読み取り、設定された等時間の.tsファイル(MPEG-2 トランスポートストリームファイル)に分割するプロセスを行う。また、

セグメンタはインデックスファイルの作成を行い.M3U8 プレイリストとして保存する。インデックスファイルはメディアファイルの可用性と位置の追跡に使用され、新しいメディアファイルが作成されるたびに更新される。インデックスファイルの一例を図4.11に示す。

図 4.11 インデックスファイル(.M3U8) ([18]より)

図4.11はストリーム全体が10秒の3つのメディアファイルに分割された場合に生成されるインデックスファイルである。

4.4.2. ディストリビューションコンポーネント

HTTP Live Streamingの一つの特徴はファイヤーウォールを超えないHTTPを介してクラ

イアントにメディアファイルを配信することである。ディストリビューションシステムはメディアファイルとインデックスファイルをHTTPでクライアントに配信するウェブサーバーかウェブキャッシュシステムである。設定としては表4.1に示してあるように.M3U8ファイルと.ts

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:1

#EXTINF:10,

http://192.168.0.101/elephantsdream-1.ts

#EXTINF:10,

#EXT-X-ENDLIST 分割された

ファイルの長さ

分割されたファイルの要求

再生の終わりを示す

(27)

表 4.1 MIMEタイプの設定ファイル拡張子 MIMEタイプ

.M3U8 application/x-mpegURLまたは

vnd.apple.mpegURL

.ts video/MP2T

4.4.3. クライアントコンポーネント

クライアントはサーバーに対してインデックスファイルを要求し、そのファイルに掲載されているメディアファイルを順番にダウンロードする。十分なデータがダウンロードされると、

クライアントはストリームの表示を開始する。クライアントは、復号キーの取得、認証または認証を許可するユーザーインターフェイスの表示、必要に応じてメディアファイルの復号を行う。これらのプロセスはクライアントがインデックスファイルで図 4.11 に示すように、

#EXT-X-ENDLIST タグを検出するまで継続する。ライブ放送の途中の場合は

#EXT-X-ENDLIST が掲載されていないのでクライアントは随時新しいインデックスファイルをロードする。

4.5. MPEG-Dynamic and Adaptive Streaming over HTTP (DASH)

HTTP Streamingにおいて、再生が途切れない(再生中にアンダーフロー状態にならない)よ

うにネットワークの帯域幅を観測しながら動的にビットレートを変化させるストリーミング技術であり、MPEG において標準化が行われた。実装例として DASHEncoder[19]が知られており、H.264とAAC でエンコードを行い、MP4ファイルを生成し、その MP4ファイルを.m4s セグメントファイルに分割し、インデックスファイル(MPD)を生成する。図5.12に示すようにクライアントは始めにこのindex ファイルを取得し、m4sセグメントを逐次取得することで、

動画再生が可能となる。また、複数ビットレートでエンコードを行い、ネットワークの状況に応じてクライアントにビットレート選択を行わせることで、適応制御を実現する。

(28)

図 4.12 MPEG-DASHの構成([19]より)

図 4.13 Relationship of Network Bandwidth and Representation

図4.13はMPEG-DASH 配信におけるネットワーク帯域とRepresentation(指定したビットレ

ート)の関係を表す。MPEG-DASHはネットワーク帯域を観測し、それに応じて適切なビットレートを選択する適応制御を実現している。

4.5.1. MPD(Media Presentation Description)[19]

MPDはXMLドキュメントであり、ビデオ、オーディオ、テキストなどメディアを構成する要素の特性が示されている。図4.14は、MPD階層データモデルを示している。MPDはperiod,

adaptation set, representation, segmentのように階層化されており、それぞれの機能を以下に

(29)

図 4.14 MPDの階層モデル([19]より)

Period

・時間軸に沿っていくプログラムの間隔

・各periodは開始時刻と持続時間を持ち、1つまたは複数のadaptation setで構成されている

Adaptation set

・1つまたは複数のメディアコンポーネントとその様々な符号化されたビットレートの選択肢に関する情報を提供している

・各adaptation setは複数のrepresentationを含む Representation

・同じメディアのエンコードされた選択肢

・ビットレート、解像度、チャネル数、またはその他の特性により、他のrepresentation と異なる

・各representation は1つまたは複数のsegmentで構成されている

Segment

・時系列でのメディアストリームの固まり

各segmentはURLを持つ。このURLはサーバー上でのアドレス指定の場所であり、HTTP

Getにより、ダウンロードすることができる。

(30)

図 4.15 MPDファイルの一例

上記の図4.15はMPDファイルの例である。クライアントはこのMPDファイルを参照することによって、解像度、メディアの種類、最小バッファ時間、平均ビットレート、異なるビットレートにおける動画の選択肢やセグメントの格納場所など様々な情報を得ることができ、最適なセグメントを要求してストリーミングを開始する。

4.5.2. DASHEncoder

DASHEncoderはDASHコンテンツを生成することが可能であり、[20]で取得することがで

きるオープンソースツールである。DASHEncoder を使うことによってユーザは各ビットレートへのエンコードや多重化を別々にやる必要がなくなる。図4.16に示すファイルのパラメータを設定してDASHEncoderを実行すると、図4.17のようにそのパラメータの値に従ってその動画をエンコード、分割、また図4.15に示すようなMPDファイルを自動生成する。

<Representation mimeType=”video/mp4” width=”1280” height=”720”startWithRAP=”true”

bandwidth=”1612755” minBufferTime=”2000”>

<InitialisationSegmentURL sourceURL=

”http://192.168.11.8/elephantsdream720p/elephantsdream720p_2000kbit/elephantsdrea m720p_2000kbit_dash.mp4”/>

…

(31)

図 4.16 DASHEncoderの設定例

図 4.17 DASHEncoderコンテンツ生成までの過程([20]より)

4.5.3. DASH-JS

DASH-JS[21]はHTML5のvideo要素を用いてウェブとDASH規格を統合したDASHプレ

#========================================

# General Options

#========================================

dest-directory : /var/www/html/elephantdream720p/

video-encoder : x264 audio-encoder : ffmpegAAC multiplexer : mp4box input-res : 1280x7200

#========================================

# x264 Options

#========================================

bitrate : 200|400|600|1000 statistics : stat.temp gop : 48

scenecut : 0 profile : baseline preset : slow

input : /home/takeshi/elephantsdream720p.y4m passes : 1

const-filesize : 0

#Additional Options for Encoding pass1 : --verbose --fps 24 pass2 : --verbose --psnr

#========================================

# MPD Options

#========================================

mpd-name : elephantsdream720p.mpd

url-root : http://localhost/elephantsdream720p/

#set-base-url duration : 9M4S transform-mpd

minBufferTime : 2.0S segDuration : 2

(32)

イヤーである。JavaScriptベースのライブラリで、Google ChromeのMedia Source APIを用い、プラグインを必要としないため、複数のデバイス上でDASHの再生を可能にし、簡単にモバイルアプリケーションを開発することができる。

図4.18はDASH-JSの構造を示したものである。Event HandlerではMedia Source APIのイベントを感知し、それをトリガーとしてMPDのファイルがダウンロードされる。MPDファ

イルはMPD Parserによって分析され、コンテンツビットレート（Representation）、各セグメ

ントの名前、解像度、バッファリング時間などの情報を取得する。また、MPDや各セグメントの取得はxmlHttpRequestを用いSegment Requesterで行われ、そこでBandwidth Estimator により各セグメントの取得時におけるネットワーク帯域の測定が行われる。帯域の測定方法は式4.1に示す。

𝑏_𝑛 =𝑤₁𝑏_𝑛−1+ 𝑤₂𝑏_𝑚

𝑤₁+ 𝑤₂ (4.1)

𝑏_𝑛−1はn-1 番目のセグメントが取得された時のの帯域であり、𝑤₁、𝑤₂は加重係数である。さらに𝑏_𝑚は n-1 番目のセグメントをダウンロードした際に計算したスループット値である。

DASH-JSの帯域予測は加重移動平均のアルゴリズムで計算されている。次に、Base Bufferは

Video Element にいくつのセグメントがプッシュされたかを秒数で管理するものであり、再生

時間も管理している。さらに、バッファレベルが一定値に下がった場合はそれをトリガーとして継続してセグメントを要求する仕組みとなっている。このバッファ値と予測されたネットワーク帯域は次のセグメントのコンテンツビットレートの選択に使用され、Adaptation Logic の switchRepresentation()メソッドによって可能となる。これによって現在の帯域に適した

Representation のコンテンツを要求することができ、動的かつアダプティブに動画配信が行わ

れる。

図 4.18 DASH-JSのアーキテクチャー

(33)

4.5.3.1. DASH-JSを用いたDASHコンテンツの再生

DASH-JSのサンプルとして以下のような簡単なコードを書くことによって、図4.19に示す

ようにDASHコンテンツがブラウザ上で再生されるようになる。

図 4.19 DASH-JS実行例

<html>

<head>

<title>DASH-NDN-JS Showcase</title>

</head>

<body>

<h1> DASH-JS Showcase</h1>

//HTML5 Video Tag

//Representation・Estimated Bandwidthのグラフ

//DASH再生としてMPDファイルを指定

video = document.querySelector('video');

var dashPlayer = new DASHPlayer

(video,"http://192.168.100.1/elephantsdream720p.mpd");

</script>

</body>

</html>

(34)

第5章交通機関を利用した先回りコンテンツ配信システム

本章では先回りコンテンツ配信システムについての説明を行う。

5.1. 概要 [22]

従来のコンテンツ配信では、無線通信などにおいてはコンテンツサーバーと受信端末の通信品質に変動が大きくなってしまうことによってコンテンツ配信に影響が出てしまい、大きな問題とされてきた。これに対し、図5.1に示すように、先回りコンテンツ配信ではコンテンツサーバーと受信端末の間に交通機関（列車等）が介在し、列車内のユーザからのコンテンツを要求後に配信スケジューラを動作させ、移動経路上の中継点(駅のサーバーなど)へコンテンツを分散し、先回り配信を実行する。交通機関が中継点に到着した際には停車時間内に中継点のサーバーから交通機関内のサーバーにコンテンツを転送し、移動中でもコンテンツ配信が列車内で完了することができる。このシステムを用いることで通信品質の時間変動にロバストなコンテンツ配信の実現が期待され、かつ長距離の無線通信を削減し、かつCCN のネットワーク内キャッシュ機能を活用することで、通信資源の有効活用や受信端末の省電力化に貢献できることも期待される。

図 5.1 先回りコンテンツ配信の動作フロー

5.2. スマートスケジューラ

先回りコンテンツ配信システムにおいて、ユーザがコンテンツを要求した後に配信スケジューラが動作し、配信コンテンツの品質、分量、コンテンツの配信の場所、そしてそのタイミングを決定し、ユーザにスムーズな動画コンテンツの再生を提供する目的としている[22]。このために最適なコンテンツのビットレート(R)を取得するには先回り条件、連続再生条件、また列車

Interest Data

Data Interest CCN backbone

command command

command

Users

Stations

Transportation system

Content servers

(35)

の停車時刻、𝐵_𝑛はサーバー・駅 n間のスループット、𝐶_𝑛は駅n・列車間のスループット、𝑆_𝑛は駅nのデータ転送量、𝐷_𝑛は列車・端末間のスループットを示す。

図 5.2 先回り配信モデル[22]

 先回り条件

列車が次の中継点（駅）へ到着する前に先回り配信としてコンテンツを取得する必要があり、

中継点nにマージン𝛼_𝑛を設定することで配信タイミングを決定する。中継点nが取得できる転送量𝑆_𝑛が列車の停車前に間に合うためには式(5.1)を満たす必要がある。

𝑆_𝑛≤ 𝐵_𝑛∗ (𝑡_𝑛− 𝑡_𝑛−𝛼_𝑛) (5.1)

 連続再生条件

列車が中継点nから中継点n+1に到着するまでにユーザが連続再生を行うためには、中継点 n で取得した転送量より低い再生速度である必要がある。コンテンツの再生速度(コンテンツビットレート)を𝑅𝑛とし、その区間におけるユーザ数を𝑗𝑛人とすると、式(5.2)という条件になる。

𝑆𝑛

𝑗_𝑛 ≥ 𝑅𝑛∗ (𝑡𝑛+1− 𝑡𝑛) (5.2)

 交通機関内再生条件

コンテンツの再生速度𝑅_𝑛は列車内で𝑗_𝑛人が共有している帯域𝐷_𝑛より低くなれなければならないので、式(5.3)を満たす必要がある。

𝐷_𝑛

𝑗_𝑛 ≥ 𝑅𝑛 (5.3)

(36)

𝐶_𝑛を駅・列車間の予測帯域だとすると、中継点nにおいて交通機関が利用できる最大転送量𝑆_𝑛は式(5.4)として表せる。

𝑆_𝑛 = 𝐶_𝑛∗ 𝛥𝑡_𝑛 (5.4)

よってこれらの式(5.1)、(5.2)、(5.3)を整理すると、式(5.5)、(5.6)、(5.7)の条件式となる。

𝑅_𝑛≤ 𝐵_𝑛∗𝛼_𝑛∗ (𝑡_𝑛− 𝑡_𝑛−1)

𝑗𝑛∗ (𝑡𝑛+1− 𝑡𝑛) (先回り) (5.5)

𝑅𝑛≤ 𝐶_𝑛∗ 𝛥𝑡_𝑛

𝑗_𝑛∗ (𝑡_𝑛+1− 𝑡_𝑛) (連続再生) (5.6)

𝑅𝑛 ≤𝐷_𝑛

𝑗_𝑛 (交通機関内再生) (5.7) これらの3式の条件をすべて満たすものが最適なコンテンツの再生速度𝑅𝑛となる。

(37)

第6章 DASH-NDN-JS

本章ではDASH-NDN-JSの実装について説明をする。

6.1. 概要

DASH-NDN-JS とは DASH-JS と NDN-JS を統合させ、DASH コンテンツを NDN 上で

Interest/Content Objectの交換によって取得し、ブラウザ上で再生をするアプリケーションで

ある。ネットワーク帯域の測定、動的に取得するビットレートを切り替えるアダプテーション制御、MPD(DASHコンテンツの情報が記述してあるxml形式のファイル)の分析、バッファ制御など、図4.18に示してあるように動作するが、Segment RequesterでのHTTP Getメソッドの代わりに Interest/Content Object メッセージのやり取りが行われる。図 6.1 は

DASH-NDN-JS の構成を表し、NDN 上でコンテンツを取得するためには WebSocket Proxy

Serverを介してNDNルータへInterestを転送する。

図 6.1 DASH-NDN-JSの構成

6.2. Chunk と Segment

DASH-NDN-JSの実装を行うにあってDASH-JS、NDN-JSの制御方式の統合を行う必要が

あった。DASH-JSは単一の動画ファイルを指定秒数ごとに分割を行ったSegmentを用いて各制御を行っている。コンテンツの取得時にはXMLHTTPRequestを使用しており、非同期通信を行う。そこで図6.2に示すようにonloadメソッドによりリクエストの結果が返ってきた場合、つまりセグメントごとのダウンロード完了時に 1 Segment をダウンロードするのにかかった時間を求め、帯域の測定やアダプテーション、そして再生バッファに Segment をプッシュする処理を行っている。

N DN Router

WebSocket Proxy Server

Producer

DASH Files Rep resentation 1 5 0 0 kb it

… 1 0 0 kb it Insert MPD File

DASH -JS

Interest Content Object

N DN Router

N DN -JS

6

(38)

図 6.2 DASH-JS onloadメソッドの処理

しかし、NDN-JSではChunkでInterestとContent Objectの交換を行っている。Chunkとは 4096 バイトに分割されたデータを示し、元のファイル名にシーケンスナンバーのように 16 進数を付着している。これはNDN RouterにおいてコンテンツをNDNレポジトリに格納する際に行われる処理で、一つのコンテンツにおける最後のChunkにはそれを示すためにヘッダの

中にFinalBlockID=1として格納される。一つのInterestは一つのChunkを指定して送られ、

データのやり取りはChunkで成立される。図6.3にはこれらの違いを表したものを示す。

図 6.3 SegmentとChunkの違い

DASH-JSとNDN-JSを統合させるためにはChunkの集合をSegmentとして結合する必要

があるため、取得したChunkをまとめてセグメント化を行った。Chunkを1から送り、順番に配列に格納し、最後(FinalBlockID=1)の Chunk が来た際にはその配列をまとめて Segment

//非同期ダウンロード(Segmentのダウンロード完了時) xhr.onload = function(e)

{

//データの取得 (1 Segment)

data=new Uint8Array(this.response);

//帯域理論値の計算

mybps = endBitrateMeasurementByID(this.timeID,data.length);

//帯域の移動平均の計算

myBandwidth.calcWeightedBandwidth(parseInt(mybps));

//帯域に応じてRepresentationを変更

adaptation.switchRepresentation();

//バッファにデータをpush buffer.push(data, 2);

};

NDN 方式を活用した高品質なコンテンツ配信に 向けた諸検討

平成 27 年度 修士論文