Comments
Description
Transcript
1.9MB - 高知工科大学
平成 25 年度 学士学位論文 StreamingQoS 基準および 伝送路 QoS 推定に関する研究 A study of streaming QoS metrics and QoS estimation of the transmission path 1140326 栗原 慎也 指導教員 島村 和典 2014 年 2 月 28 日 高知工科大学 情報学群 要 旨 StreamingQoS 基準および 伝送路 QoS 推定に関する研究 栗原 慎也 近年, インターネットの高速化に伴い, 映像コンテンツを配信するサービスが普及してい る. これらのサービスの多くは, 順次再生が可能であることと, データがクライアントの端末 上に残らないことからストリーミング方式を採用している. その中でも本稿では, ユーザビ リティに優れているユニキャスト通信方式を用いたストリーミング方式を取り上げる. この 方式の利点は, 再生までの待ち時間が短いことである. しかし, クライアントとサーバが一対 一の関係になるため, ネットワークに負荷がかかり, ストリーミング再生断絶が発生する問 題点がある. そのため, クライアントの受信帯域がコンテンツの理想帯域よりも低い場合に おいて, 再生断絶を抑制するアーキテクチャが必要である. そこで, クライアントのバッファ とネットワーク測定方法に着目し, クライアントの受信帯域の変化による再生断絶のバッ ファリング管理方式を提案した. 本提案方式は, クライアント・アプライアンス内に設ける Network status Investigation System(以下 NIS) と Waiting-time Calculation System(以下 WCS) から構成する. NIS にはクライアントの受信帯域取得機能及び, バッファリング管理機能を持たせ，WCS には 事前バッファリング時間算出機能を持たせる. NIS は RTP パケットの到着間隔からクライ アントの受信帯域を測定し，WCS は NIS が測定した受信帯域で再生前にバッファリングを 行う時間（事前バッファリング時間）を算出する．その後 NIS が WCS が算出した時間分だ けバッファリングを行い，再生を開始する． ストリーミング方式における QoS 基準は存在しないが，再生断絶が発生した時にそのコ –i– ンテンツを継続して視聴するために待機可能な時間は 2 秒以内であると既存研究で示されて いる．このことから，この再生断絶発生時間を本提案方式における QoS 基準の根拠にした． 本提案方式をクライアント内に構築し，5 分及び 120 分のコンテンツを用いてそれぞれの コンテンツにおける事前バッファリング時間の算出及び，既存の再生方式と本制御方式にお ける断絶発生率を比較した．事前バッファリング時間は 5 分のコンテンツで 1.13 秒，120 分のコンテンツで 257.02 秒となり，どちらもコンテンツ再生時間の 5 ％未満の割合となっ た．また，断絶発生率は既存の再生方式に比べて両コンテンツ共に 99.2 ％以上の低下を確 認できた． 以上の結果より，本提案方式をバッファリング制御機構に取り入れることで，再生断絶に 関する QoS を充分に満たせることを示した． キーワード ストリーミング, 再生断絶, 待機時間, バッファリング – ii – Abstract A study of streaming QoS metrics and QoS estimation of the transmission path Shinya KURIHARA Recent years, services which distribute moving video contents are penetrated widely according to the growth of the Internet throughtout. In many case of the services, the streaming protocol has been adopted, because it allows to start early playback and it does not remain the data in the client terminal. This paper focuses on the streaming method using unicast deliverly due to the excellence in usability. This method has the advantage in reproducing within short waiting time for the individual user. On the other hand, it has a problem which streaming playback freezing might be happened in case of network congestion. The playback freezing is happend in the case that the client reception band becomes lower than the regurated bandwidth of the content streaming. This paper aimed to solve the problem by way of buffering only on the client. The buffering management scheme which absorbs change of the receiving bandwidth for a client was proposed. This proposal method was consisted of NIS(Network status Investigation System) and WCS(Waiting-time Calculation System).NIS has a bandwidth of client reception measurement function and a buffering management function. WCS has a waiting time calculation function. First, NIS measures the bandwidth of client reception by RTP packet arrival intervals. Second, WCS calculates waiting time for buffering before playback using the NIS’s measurement result. Finally, NIS does buffering in waiting time – iii – and starts playback. There is not clear streaming QoS critical parameter now. An existing research shows that if there is a streaming playback freezing, user’s waitable time for continuing viewing is less than two seconds. By this existing research, a probability of streaming playback freezing regarded the QoS critical parameter as this proposal method. This paper built a proposal method in the client terminal and verified it by two experiments to clarify the usability. These experiments used a 5 minute content and a 120 minute content. First, each waiting times for these contents were calculated to check the method availability. Next, the probabilities of playback in the proposal method were compared with those in normal playback cases. Result of the experiments, waiting time in 5 minute content was 1.13 seconds and waiting time in 120 minute content was 257.02 seconds. These waiting times in both cases were rated less than 5 percent of the total playback time. The probabilities of playback freezing using this proposal method was decreased 99.2 ％ compared to the normal playback in cases of a 5 minute content and a 120 minute content. The result shows that this proposal method could improve streaming QoS of the playback freezing. The streaming QoS should be considered to the waiting time estimation value using the proposal scheme. key words Streaming, interruption during playing, Waiting-time, Buffering – iv – 目次 第1章 1.1 背景と目的 1 研究背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 近年のインターネット利用状況 . . . . . . . . . . . . . . . . . . . . 1 1.1.2 ストリーミングサービスの現状 . . . . . . . . . . . . . . . . . . . . 2 1.2 再生断絶の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 研究目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 既存の関連技術 5 動画配信の方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 ダウンロード方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2 ストリーミング方式 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3 プログレッシブダウンロード方式 . . . . . . . . . . . . . . . . . . . 6 2.1.4 各方式の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Video on Demand サービス . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Video on Demand サービスとは . . . . . . . . . . . . . . . . . . . 7 2.2.2 マルチキャスト VOD 方式 . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3 ユニキャスト VOD 方式 . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.4 Near Video on Demand 方式 . . . . . . . . . . . . . . . . . . . . . 8 ストリーミングに関するプロトコル . . . . . . . . . . . . . . . . . . . . . 8 2.3.1 RTSP について . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 RTP について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.3 RTCP について . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.4 既存のストリーミング方式の問題点 11 第2章 2.1 2.2 2.3 –v– . . . . . . . . . . . . . . . . . 目次 第3章 提案するストリーミング制御方式 12 3.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 提案方式に用いる情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 NIS（Network status Investigation System） . . . . . . . . . . . . . . . 14 3.4 WCS（Waiting-time Calculation System） . . . . . . . . . . . . . . . . 16 3.5 提案方式の動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 ストリーミング方式における QoS 基準に関する議論 20 ストリーミング方式おける QoS 基準に関する議論 . . . . . . . . . . . . . 20 検証実験 21 5.1 実験に使用したツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 環境構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3 シミュレーションの流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.5 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.6 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 結論 25 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 第4章 4.1 第5章 第6章 6.1 謝辞 27 参考文献 28 – vi – 図目次 1.1 インターネット利用人口の推移 . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 インターネット利用端末の種類 . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 RTP データ転送パケットのフォーマット . . . . . . . . . . . . . . . . . . . 10 3.1 再生断絶抑制のためのシステム概要図 . . . . . . . . . . . . . . . . . . . . 13 3.2 測定時間ごとの実測結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 パレート分布の確率密度関数グラフ . . . . . . . . . . . . . . . . . . . . . . 16 3.4 提案方式の動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 – vii – 表目次 5.1 シミュレーション機器の環境構成 . . . . . . . . . . . . . . . . . . . . . . . 22 5.2 シミュレーションで用いたコンテンツ情報 . . . . . . . . . . . . . . . . . . 22 5.3 シミュレーション結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 – viii – 第1章 背景と目的 1.1 1.1.1 研究背景 近年のインターネット利用状況 近年，インターネットの利用人口が増加している. インターネットの利用人口の推移を図 1.1 に, インターネット利用端末の種類を図 1.2 に示す. 図 1.1 インターネット利用人口の推移 平成 24 年度末におけるインターネットの利用者数は 9652 万人であり, 前年に比べ約 42 万人の増加 (前年比 0.4 ％増)，人口普及率は 79.5 ％ (前年差 0.4 ポイント増) となってい –1– 1.1 研究背景 図 1.2 インターネット利用端末の種類 る. 個人のインターネット利用端末の種類として, 最も使用率が高い端末は, 自宅のパソコ ン (59.5 ％) である. 次いで携帯電話 (34.1 ％), 自宅以外のパソコン (32.8 ％) となっている [1]. また、高速な通信回線の普及により実現されるコンピュータネットワーク, ブロードバ ンドの利用環境も整備されている．FTTH（Fiber To The Home）及び下り伝送御速度 30 Mbps 以上のケーブルインターネットの世帯カバー率は 2011 年 3 月末で 92.7 ％ となって いる. 利用環境の整備・高速回線の普及により, インターネットの利用目的としてデジタル コンテンツ（音楽・音声, 映像, ゲームソフト等）の入手, 聴取が拡大している． 1.1.2 ストリーミングサービスの現状 現在, 多くの Web サイトやプロパイダからストリーミングサービスが提供されている. コ ンテンツの内容は音楽やニュース, 映画, アニメ等様々である. 配信されるコンテンツの品質 はユーザのネットワーク帯域に合わせて数種類のビットレートが用意されている. その一例 として, アナログモデムや ISDN(Integrated Services Digital Network) 向けの数 10kbps, –2– 1.2 再生断絶の問題点 ADSL(Asymmetric Digital Subscriber Line) 向けの 100kbps，数 Mbps, FTTH 等光ファ イバアクセス方式向けの数 Mbps 数十 Mbps とユーザのネットワーク帯域によって３種類 のビットレートが用意されている. 様々なストリーミングサービスが提供されていることか ら, ユーザも日常的に利用する機会が増加している. しかし, クライアント・サーバ間のネッ トワーク帯域の変化によっては, コンテンツの再生が途中で止まりデータの読み込みを行う 現象（再生断絶）が目立っている [2]. 1.2 再生断絶の問題点 コンテンツの再生は, 待ち時間が短く視聴中に再生が中断しないことが理想である. スト リーミングサービスでは長時間のコンテンツになるほど, クライアント・サーバ間のネット ワーク帯域変化の影響を受ける. 再生断絶が発生する原因として, クライアント・サーバ間 のデータ転送がコンテンツの再生までに間に合わないことが挙げられる. これは, ユニキャ スト通信方式を用いた場合, クライアントとサーバが一対一で通信を行うため，ネットワー クに負荷がかかるためである. ネットワークに負荷がかかるとパケットロスや遅延が生じ, 結果としてコンテンツデータがクライアントに届かなくなり, 再生断絶の発生に繋がること が考えられる. また, クライアントのデータ受信速度は一定ではないため, 配信サーバからク ライアントまでの距離や経路, ネットワークの負荷によるタイムラグや遅延に幅（揺らぎ） が生じる．従って，再生断絶を抑制するためには, 揺らぎの吸収が重要となる. 1.3 研究目的 これまでのネットワーク制御ではストリーミング方式における QoS は考慮されていな かった．しかし，ストリーミング方式を用いたコンテンツ配信サービスの増加により，スト リーミング方式を利用する機会が増加している．そのため，ストリーミング QoS の基準を 設定し，その基準を用いてストリーミング配信を評価する必要がある．ストリーミング方式 はネットワークの品質変化の影響を受けやすいことから，再生断絶の発生率をストリーミン –3– 1.4 論文の構成 グ QoS の基準と設定できないかを検討した．本稿では，クライアント側で伝送路 QoS の推 定を行い，ストリーミング QoS を向上させることを目的とする． 1.4 論文の構成 本論文は，本章を含めた 6 章で構成する．本章では，本研究の背景と目的，再生断絶の問 題点について述べた．以降，第 2 章では, 既存の関連技術について述べる．第 3 章では，提 案するストリーミング制御方式について述べる．第 4 章では，ストリーミング方式における QoS パラメータに関する議論について述べる．第 5 章では，本提案方式の有用性を確認す るために行った検証とその結果及び，今後の課題について述べる．第 6 章では，本研究のま とめについて述べる． –4– 第2章 既存の関連技術 2.1 動画配信の方式 高速回線の普及からデジタルコンテンツの入手，聴取に関するサービスが増加し，それに 伴ってユーザの需要も増加している．映像コンテンツ配信サービスの方式として，「ダウン ロード方式」，「ストリーミング方式」， 「プログレッシブダウンロード方式」の三種類が存在 する．各方式の説明を以下に記述する． 2.1.1 ダウンロード方式 ダウンロード方式はコンテンツを取得する際に，一時的にクライアント側で全コンテンツ データをダウンロードしてからコンテンツ再生を開始する方式である．ダウンロードが終了 するまでコンテンツの再生が開始出来ないため，サイズが大きいコンテンツであればある 程，再生までの待ち時間が増加する．さらに，ダウンロード中はコンテンツ配信先からの ネットワーク帯域に左右されるため，ダウンロード時間が不特定となる．そのため，ネッ トワーク帯域によっては再生開始までの待ち時間が非常に大きくなる可能性がある. その反 面，コンテンツデータは全てダウンロードしてから再生するため，一度再生を開始すれば ネットワークの環境に影響されずに安定した視聴が可能である．コンテンツデータはクライ アントのハードディスクに残る可能性があるため，コンピュータウイルスによる再配布の恐 れが生じる．そのため，著作権等の対応にも注意しなければならない． –5– 2.1 動画配信の方式 2.1.2 ストリーミング方式 ストリーミング方式は，コンテンツデータをバッファにダウンロード（バッファリング） しながら順次再生する方式である．バッファに蓄積されたコンテンツデータは，再生が終了 した部分から順次破棄される．再生に必要なコンテンツデータをダウンロードしつつ，順次 再生することにより，ダウンロード方式と比較して，クライアント側での再生までの待機時 間を短縮することができる．また，ストリーミング配信は User Datagram Protocol（UDP） を用いており，サイズの大きなコンテンツであっても効率の良い転送が可能である．欠点と して，パケットロスやデータ誤り等の再生品質の保証を行わない点がある．ダウンロード方 式とは異なり，コンテンツデータをクライアントのハードディスクに保存することが無いた め，再配布を危惧する必要がない． 2.1.3 プログレッシブダウンロード方式 プログレッシブダウンロード方式は，コンテンツデータをクライアントのキャッシュにダ ウンロードを行い，同時にダウンロードされた部分から順次再生を行う方式である．スト リーミング方式では配信に UDP を用いていたのに対し，プログレッシブダウンロード方式 では Hyper Text Transfer Protocol（HTTP）を用いて配信を行うため，パケットロスによ る再生品質の低下がないことがストリーミング方式には無い利点として挙げられる．その反 面，ダウンロード方式と同様にコンテンツデータをクライアントのハードディスクに保存す るため，再配布の恐れが生じる． 2.1.4 各方式の評価 ダウンロード方式は，コンテンツ再生開始後はネットワークへの接続が不要であることか ら，ネットワークに常時接続できない場合に適した視聴方法である．ストリーミング方式 は，視聴を早く開始したい場合に適した視聴方法である．コンテンツがクライアント側に残 らないことから，著作権が発生するコンテンツの配信に適している．プログレッシブダウン –6– 2.2 Video on Demand サービス ロード方式は，短い待機時間でかつ高品質でしたいときに適した配信方法である．TCP の HTTP を用いているため，長時間コンテンツの配信中にネットワークの受信帯域が悪化す ると，ストリーミング方式よりも早く停止するので，短時間の高品質コンテンツを配信する のに適している． 2.2 Video on Demand サービス 2.2.1 Video on Demand サービスとは 映像コンテンツを配信するサービスの一つとして，Video on Demand（VOD）サービス が普及している．VOD サービスは，クライアントからの映像コンテンツの要求に応じてリ アルタイム配信を行うサービスである．現在は，静的な動画のみに限らず動的に配信を行う VOD もサービスとして展開され始めている．VOD サービスの特徴として，クライアント は配信時間に拘束されることなく，コンテンツを視聴することが可能であることが挙げられ る．これは VOD サービスが，配信したコンテンツデータを配信終了後もサーバに保持して いるためである．VOD の配信方式には大きく分けて 3 つの配信方式が存在する．その各方 式を以下に示す． 2.2.2 マルチキャスト VOD 方式 マルチキャスト VOD は，コンテンツの配信にマルチキャスト通信方式を用いて配信を行 う VOD サービスである．この方式では，サーバが配信を行うクライアントの数だけコンテ ンツをコピーして一斉配信を行う．そのため，ネットワークに対する負荷を抑制することが 可能である．コンテンツの配信を受けるクライアント側でマルチキャストグループを作成 し，参加する必要がある．マルチキャストグループに参加してコンテンツ配信を行うため， 映像コンテンツの操作ができない問題点がある． –7– 2.3 ストリーミングに関するプロトコル 2.2.3 ユニキャスト VOD 方式 ユニキャスト VOD は，コンテンツの配信にユニキャスト通信方式を用いて配信を行う VOD サービスである．マルチキャスト VOD 方式とは異なり，クライアントがマルチキャ ストグループに参加する必要が無いため，コンテンツの操作が可能である．そのため，クラ イアントは自宅内でビデオをレンタルするのと同様のサービスを受けることができる．しか し，配信を行うサーバとクライアントが一対一で通信を行うため，配信するクライアント数 が多くなるほどネットワーク帯域の負荷が増大するという問題点がある． 2.2.4 Near Video on Demand 方式 Near Video on Demand 方式（NVOD 方式）はサーバが一定時間毎に映像コンテンツを 複数のチャネルを用いて配信を行う VOD サービスである．チャネルを複数に分散させるこ とにより，一つのチャネルにかかる負荷を抑えることができる．また，配信を行うサーバ側 の配信時間が複数あることから，クライアント側は配信間隔単位で視聴時間の指定をするこ とができる．マルチキャスト VOD と同様にコンテンツの操作を行うことができないという 問題点がある． 2.3 ストリーミングに関するプロトコル コンテンツの配信方式の一つとしてストリーミング方式がある．ストリーミング方式で は通信プロトコルとして UDP を用いている．UDP はコネクションレス型の通信プロト コルであるため，リアルタイム性を重視するストリーミング配信に適している．しかし， UDP はストリーミング配信の品質保証が行わないため，他のプロトコルを用いて品質保 証を行う．本節では，ストリーミング配信において主要なストリーミングプロトコルであ る RTSP(Real-time Streaming Protocol)，RTP(Real-time Transport Protocol) そして RTCP(RTP Control Protocol) の三つについて説明を行う． –8– 2.3 ストリーミングに関するプロトコル 2.3.1 RTSP について RTSP（Real-time Streaming Protocol）は，クライアント・サーバ型のマルチメディア プレゼンテーション制御プロトコルである．ストリーミングサーバに対して，再生・停止・ 早送り・巻き戻し等のコンテンツの制御を行うことが可能である．IP ネットワークで映像 や音声等・マルチメディアを効率良く配信することを目的として設計されている．RTSP は Web の既存のインフラを利用し大量の視聴者への配信が可能である．また，視聴者 1 人に 対してオンデマンド配信を行わせることもできる．1998 年 4 月に IETF 標準として勧告さ れている． 2.3.2 RTP について RTP（Real-time Transport Protocol）は，音声や映像をストリーミング再生するのに 用いるデータ転送プロトコルである．1996 年に提唱されたプロトコルで，現在では Quick Time や Real Player が RTP を採用している．RTP は UDP によるデータ転送を行い， RTCP（RTP Control Protocol）による通信状態レポートとセットで用いられる．UDP と の違いは，伝送するメディアの種類やパケットごとの再生タイミング，パケットの損失，再 生順序の情報を有していることである．クライアントは RTP パケットを受信することで， リアルタイムの動画や音声といったコンテンツを正しく再生することが可能となる．RTP はデータ転送プロトコルと RTCP により構成される．ストリーミング配信で利用される RTP データ転送パケットのフォーマットを 2.1 に示す．RTP データ転送パケットには，ペ イロードタイプ (PT:Payload Type)，シーケンス番号 (Sequence Number)，タイムスタン プ (Timestamp)，同期ソース識別 (SSRC:Synchronization SouRCe identifier) 等が含まれ る．ペイロードタイプ (PT) は，メディアデータがどの圧縮方式を用いて圧縮されたかを 判別する際に使用される．シーケンス番号は，RTP パケットの順番が正しく受信できてい るかを通知するための順序番号である．タイムスタンプは，メディアデータの再生をスケ ジュールする時に利用される．同期ソースは，RTP セッション内の参加者の識別に用いら –9– 2.3 ストリーミングに関するプロトコル 図 2.1 RTP データ転送パケットのフォーマット れる．これらの情報を用いることで順序の誤差のない再生，他ユーザとの同期再生が可能と なる． 2.3.3 RTCP について RTCP（RTP Control Protocol）は，データフロー制御及び送信者と受信者の情報を記述 するためのプロトコルである．RTP パケットを送信した際に同時に送信され，送信される コンテンツの品質保証を行う．IP マルチキャストを用いた音声通信や動画通信を行う様々 なアプリケーションで利用されている．RTCP パケットには，受信者での受信品質に関す る情報を送信する Receiver Report(RR) パケット，送信者からのストリームに関する情報 を送信する Sender Report(SR) パケット，RTP セッションへの参加者の識別や電子メール アドレス，電話番号などの補足情報を送信する Source DEScription(SDES) パケット，参 加者がセッションを退出したことを通知する BYE，アプリケーションが独自拡張を行うた めに利用する APPlicaiton-defined(APP) の五種類のパケットが定義されている．これら のパケットを用いて RTP で送信するデータ品質を調整することで，ネットワーク帯域の変 – 10 – 2.3 ストリーミングに関するプロトコル 化に柔軟に対応して RTP パケットの送信を行うことが可能となる． 2.3.4 既存のストリーミング方式の問題点 RTSP，RTP，RTCP を用いたストリーミング方式の問題として，再生断絶の防止がで きないことが挙げられる．ストリーミング方式では，RTCP を用いてクライアントの受信 帯域をサーバに送信することで，サーバにクライアントのネットワーク状態に応じた柔軟な パケット送信を要求することができる．そのため，クライアントの受信帯域がコンテンツの ビットレートを下回り，再生に必要なパケットが不足した場合であっても，サーバに受信帯 域以上のビットレートでのデータ転送を要求することができる．しかし，受信帯域がサーバ の送信ビットレートを下回っているため，クライアントはサーバに要求したビットレートで パケットを受信することできない．またその要求によって，輻輳を引き起こす可能性が高ま る．輻輳が発生した場合，UDP を用いて転送している RTP パケットは廃棄される可能性 があるため，パケットロスの増加によりストリーミング品質の更なる低下を招く．そのため 再生断絶を防止するためには，これらのプロトコル以外での制御が必要となる． – 11 – 第3章 提案するストリーミング制御方式 本章では，本研究で提案するストリーミング制御方式について説明する． 3.1 概要 ストリーミング方式の問題点として，コンテンツの理想帯域がクライアントの受信帯域を 上回った場合に, コンテンツの再生断絶が発生することが挙げられる．その要因として，ユ ニキャスト通信方式において，クライアント・サーバ間のネットワーク帯域に負荷が発生し， RTP パケットの受信に遅延が起こることが考えられる．その結果，コンテンツデータの転 送がコンテンツの再生に間に合わないために断絶が発生する．本研究で提案するストリーミ ング制御方式は，クライアント・サーバ間のネットワーク帯域変化の影響や遅延の揺らぎを バッファリング制御により抑制する．具体的には，クライアントが接続しているネットワー ク帯域の状況を監視し，バッファリングによる再生制御を行うことで断絶発生確率を低確率 に抑制する．提案方式における再生断絶抑制のためのシステム概要図を図 3.1 に示す． – 12 – 3.2 提案方式に用いる情報 図 3.1 再生断絶抑制のためのシステム概要図 システムの構成要素はストリーミングサーバとクライアントの 2 つに分けられる．スト リーミングサーバはクライアントに対してコンテンツを配信する機能を担う．本提案方式 では，クライアント側にネットワーク状態推定機能（NIS：Network status Investigation System）と待機時間算出機能（WCS：Waiting-time Calculation System）を新規実装さ せる．NIS は RTP パケットの到着間隔からコンテンツ再生時のネットワーク状態を測定 し，WCS が算出した時間分のバッファリングを再生前に行う機能である．WCS は NIS が 測定したネットワーク状態を基に，コンテンツ再生前のバッファリングを行う時間（事前 バッファリング時間）を算出する機能である．これらの機能を用いて再生断絶の発生を抑制 する． 3.2 提案方式に用いる情報 事前バッファリング時間を正確に算出するために，本提案方式ではクライアントの RTP パケットの到着間隔を用いて，クライアントの受信帯域を推定する．その後，推定した受 信帯域で全てのコンテンツデータをバッファリングするのにかかる時間（推定バッファ リング時間）を計算し，その時間からコンテンツ再生時間を減算した値を事前バッファリ ング時間とする．これらの処理を NIS（Network status Investigation System）と WCS （Waiting-time Calculation System）を用いて実現する． – 13 – 3.3 NIS（Network status Investigation System） 3.3 NIS（Network status Investigation System） NIS（Network status Investigation System）は WCS で算出する事前バッファリング時 間のために，クライアントの受信帯域を測定する機能と，WCS が算出した事前バッファリ ング時間の長さだけコンテンツ再生を禁止するというバッファリング制御機能を持つシステ ムである．バッファリング制御において，WCS から通知された事前バッファリング時間が 0 であった場合は，コンテンツが再生可能になり次第，再生を開始する．クライアントの受 信帯域の測定には，クライアントが受信した RTP パケットの到着間隔を用いる．到着間隔 の測定は NTP を利用し，到着した RTP パケットの到着時刻から一つ前の RTP パケット の到着時刻を減算することで，各 RTP パケットの到着間隔を算出する．次に，この測定を 行う時間についてどの程度の測定時間が適切であるかを考える必要がある．測定するパケッ トは再生で用いる RTP パケットであるため，この測定もバッファリングの一部と捉えるこ とができる．そのため，算出されると推測される事前バッファリング時間以内の測定時間で あれば，測定時間が長くなれば事前バッファリング時間が減少すると考えられる．その理由 は，収集する RTP パケットの到着間隔の個数も増加するとその分布が母集団の分布に近づ くため，より正確な事前バッファリング時間を算出できるからである．しかし，算出される と推測される事前バッファリング時間を事前に知ることはできないので，適切な測定時間の 値を決定しなければならない，そこで，測定時間を変えてパケット到着間隔の揺らぎの分布 を実測にて調査した．測定時間ごとの実測結果を図 3.2 に示す． – 14 – 3.3 NIS（Network status Investigation System） 図 3.2 測定時間ごとの実測結果 それぞれの図において，到着間隔が 5ms 15ms の部分の分布を比較すると，測定時間が 1 秒と 2 秒の結果は測定時間が 5 秒以上の結果よりも分布にばらつきが見られた．また，測定 時間が 5 秒・10 秒・20 秒・30 秒の結果において，到着間隔が 5ms・15ms の部分の分布は 測定時間が異なっても大きなばらつきは見られない．これは，測定時間が 5 秒以上で収集し た標本の分布が母集団の分布と近似しているからであると考えられる．これらの結果より， NIS でネットワーク状態を測定する時間は最低でも 5 秒以上必要であると推測できる． – 15 – 3.4 WCS（Waiting-time Calculation System） 3.4 WCS（Waiting-time Calculation System） WCS（Waiting-time Calculation System）は NIS が収集した RTP パケットの到着間隔 を基に，コンテンツ再生前のバッファリング時間（事前バッファリング時間）を算出する 機能である．クライアントの受信帯域は一定ではなく常に変化するため，収集した RTP パ ケットの到着間隔から今後のネットワーク帯域を平均値や中央値といった定数で算出する ことはできない．そこで，RTP パケットの到着間隔の揺らぎの分布を調査したところ，パ レート分布に近似することができた [3]．以下にパレート分布の確率密度関数グラフを図 3.3 に示す． 図 3.3 パレート分布の確率密度関数グラフ – 16 – 3.4 WCS（Waiting-time Calculation System） 確率密度関数のグラフにおいて，ある範囲の確率は確率密度関数の定積分で求めることが できる．図 3.3 よりある RTP パケットの到着間隔が長くなるほど，その間隔で到着する確 率が低下することが読み取れる．つまり，到着間隔が長いパケットほど，全体のパケット数 におけるその個数は減少する．そこでこの性質を利用して，最も短い到着間隔から，ある閾 値の到着間隔までに到着したパケットを許容パケットとし，その閾値よりも長い到着間隔を 持つパケットはストリーミング再生に無効なパケットとみなす．この時の閾値は，収集した パケットの 99.5 ％が許容パケットとなるように設定する．これは，ストリーミング方式に おいて，パケット欠損率が 0.05 ％を超えると再生に影響を与えることが既存研究で示され ているためである [3]．この閾値内の到着間隔を持つ RTP パケットの到着間隔を一定の幅 で正規化を行う．そして，収集した全パケット数に対する各到着間隔に到着したパケットの 割合を算出する．以後のネットワークでは，RTP パケットが算出した割合の到着分布で到 着すると想定する．次に，コンテンツデータ全体を RTP パケットの個数に変換し，各到着 間隔の割合を乗算する．これにより，各到着間隔で到着する RTP パケットの個数が判明す る．そして，各到着間隔とその到着間隔で到着すると推定した RTP パケットの個数を乗算 して合算することで，全てのコンテンツデータをバッファリングするのに時間（推定バッ ファリング時間）を算出する．ここで，推定バッファリング時間とコンテンツの再生時間を 比較する．推定バッファリング時間がコンテンツの再生時間よりも短い場合は，バッファリ ング中に全てのコンテンツデータの受信が完了するので，再生断絶は発生しないと考えられ る．従ってコンテンツが再生可能になり次第，再生を開始する．この時，WCS は NIS に事 前バッファリング時間として 0 を通知する．推定バッファリング時間がコンテンツの再生時 間よりも長い場合は，再生開始を遅らせる必要がある．再生開始を遅らせる時間（事前バッ ファリング時間）として，WCS は推定バッファリング時間とコンテンツの再生時間との差 を NIS に通知する．以上が事前バッファリング時間の算出方法である． – 17 – 3.5 提案方式の動作 3.5 提案方式の動作 本提案方式はクライアント内に構築した機能である．図 3.4 に提案方式の動作を示す． 図 3.4 提案方式の動作 – 18 – 3.5 提案方式の動作 提案方式の動作について説明する． 1. クライアントはサーバにコンテンツ配信要求を送信する． 2. NIS は事前バッファリング時間が経過するまで再生を禁止する． 3. サーバから最初の RTP パケットが到着後，一定時間までに到着した RTP パケットの 到着間隔を収集する（ネットワークの状態把握）． 4. 一定時間経過後，NIS は WCS に収集した RTP パケットの到着間隔の分布を送信する． 5. WCS は NIS から受信した RTP パケットの到着間隔を昇順ソートし，その個数を計算 する． 6. WCS は RTP パケットの到着間隔の個数の 99.5 ％にあたる到着間隔を算出する（許容 パケットの選別）． 7. WCS は到着間隔の一定の幅で正規化を行い，収集した個数における各割合を算出する． 8. WCS はコンテンツ全体を RTP パケット数に変換する． 9. WCS はコンテンツ全体の RTP パケット数に手順「7」で算出した各到着間隔個数の割 合と，その到着間隔を乗算し，その和を算出する（推定バッファリング時間の算出）． 10. 推定バッファリング時間とコンテンツ再生時間を比較する． • 推定バッファリング時間よりもコンテンツ再生時間が長い場合：NIS に待機時間 0 を通知する（コンテンツが再生可能になり次第，再生を開始する）． • 推定バッファリング時間よりもコンテンツ再生時間が短い場合：事前バッファリン グ時間の算出を行う． 11. 推定バッファリング時間からコンテンツ再生時間を減算する（事前バッファリング時間 の算出）． 12. WCS は事前バッファリング時間の値を NIS に送信する． 13. NIS は事前バッファリング時間が経過するまでバッファリングを行う． 14. 事前バッファリング時間経過後，コンテンツ再生を開始する． – 19 – 第4章 ストリーミング方式における QoS 基準に関する議論 4.1 ストリーミング方式おける QoS 基準に関する議論 現状，ストリーミング方式における QoS 基準は存在しない．ストリーミング方式におけ る QoS 基準となる候補として，コンテンツの品質継続率と再生断絶率の二つが考えられる． コンテンツ再生中は品質が維持された上でその再生が継続されることが理想である．常にク ライアントの受信帯域がコンテンツの理想ビットレートよりも上であればこの二つを同時に 満たすことができる．しかし，ネットワーク帯域は常に一定ではなく不規則な変化をしてい る．そのため，視聴開始時にはコンテンツを高品質で視聴できる受信帯域であったとして も，その受信帯域が視聴終了まで継続されるという保証はない．従って，受信帯域の減少で 再生コンテンツが現状の品質を継続した再生が困難になった場合，再生品質を重視して一旦 再生を停止した上でコンテンツデータの受信をするか，視聴継続を重視して再生コンテンツ の品質を受信ビットレート以下になるように低下させて視聴を続けるか，何れかの選択をし なければならない．ここで，ストリーミング方式においてコンテンツ視聴時に再生断絶が発 生した場合「継続して視聴するために待機可能な時間は 2 秒が限度である」と既存研究で示 されている [4]．待機可能な時間が「2 秒」という非常に短い時間であることから，再生断 絶がストリーミング再生の品質を著しく低下させると考えられる．従って，ストリーミング 方式では再生断絶率が QoS 基準として重視されると判断し，本提案方式における QoS パラ メータとして再生断絶の発生率を用いる． – 20 – 第5章 検証実験 本提案方式の有用性について検証実験を行った．その詳細を以下に記す． 5.1 実験に使用したツール 本提案方式の構築するためにオープンソースのネットワークシミュレータ「NS-3」を用い た [5]．ネットワークシミュレータは，コンピュータ上に仮想ネットワークを構築し実験を 行うことができるシミュレータである．インターネット上でのデータ通信や，それに伴って 発生する様々な事象を調べるために用いられる．実際にネットワークを構築するには膨大な コストや時間を要するが，仮想的にネットワークを構築することでコストと時間を削減する ことが可能となる． 5.2 環境構成 シミュレーション機器の環境構成を表 5.1 に，シミュレーションで用いたコンテンツ情報 を表 5.2 に示す． – 21 – 5.3 シミュレーションの流れ 表 5.1 シミュレーション機器の環境構成 項目 値 ストリーミングサーバ 1台 クライアント 1台 パケットサイズ 1,500 Bytes 表 5.2 シミュレーションで用いたコンテンツ情報 項目 値 再生形式 MPEG-4 再生時間 5 分, 120 分 コンテンツビットレート 2,300Kbps シミュレーション機器の環境構成はストリーミングサーバ 1 台，クライアント 1 台とし た．また，送信するパケットサイズを 1,500Byte とした．コンテンツは，5 分及び 120 分の 二種類の MPEG-4 形式を用いた．二種類のコンテンツを用いた理由は，コンテンツの再生 時間による断絶発生率の変化を調査するためである．両コンテンツ共に，MPEG-4 形式で ビットレートは 2,300Kbps のものを用いた．なお，クライアントの受信帯域は再生コンテ ンツのビットレートの上下 10 ％の範囲の値を算出するランダム関数を用いて決定した． 5.3 シミュレーションの流れ 本シミュレーションでは，再生コンテンツのビットレートの上下 10 ％の範囲でランダム に変化するネットワークにおいて，RTP パケットをサーバからクライアントへ 5 秒間送信 し，その到着間隔を測定した．その後許容パケットの選出と到着間隔の正規化を行い，推定 バッファリング時間を計算し，その値から事前バッファリング時間を算出した．次に，コン – 22 – 5.4 結果 テンツを既存の方式で再生した時と，本提案方式を用いて待機時間後に再生した時とでそれ ぞれの再生断絶の発生率を算出して比較を行った． 5.4 結果 本シミュレーションによって得られた待機時間及び再生断絶率を表 5.3 に示す． 表 5.3 シミュレーション結果 コンテンツ再生時間 5分 120 分 事前バッファリング時間 1.13 秒 257.02 秒 再生断絶率（既存方式） 4.92 ％ 6.15 ％ 再生断絶率（提案方式） 0.04 ％ 0.05 ％ 断絶発生減少率 99.2 ％ 99.1 ％ 事前バッファリング時間は 5 分のコンテンツで 1.13 秒，120 分のコンテンツで 257.02 秒 となった．これは両コンテンツ共に，再生時間の 5 ％未満の割合の値である．また既存の方 式で再生した時と比較して，本提案方式を用いて事前バッファリング時間後に再生した時の 再生断絶率は，両コンテンツ共に 99 ％以上の減少を確認した． 5.5 考察 本提案方式の事前バッファリング時間算出方法では，コンテンツ再生時間が長くなれば， 事前バッファリング時間も増加する．シミュレーション結果より，120 分のコンテンツの事 前バッファリング時間は再生時間の 5 ％の割合である．よって，120 分以内のコンテンツで あれば再生時間の 5 ％未満の事前バッファリング時間で再生を開始できる．次に既存の再生 方式での再生した時と本提案方式を用いて事前バッファリング時間後に再生した時の再生断 絶率の比較において，5 分のコンテンツ及び 120 分のコンテンツのどちらにおいても，再生 断絶率を 99 ％以上抑制することができた．この結果から，120 分以内のコンテンツであれ – 23 – 5.6 今後の課題 ばその再生時間の長さに関係なく，99 ％以上の再生断絶率の減少を見込むことができると いえる．この二つのシミュレーション結果により，本提案方式を用いることで 120 分以内の コンテンツであれば再生時間の 5 ％の時間だけ再生を禁止し，バッファリングを行うことに より，再生時の断絶発生率を 99 ％以上減少させることが可能であると判明した．本提案方 式を動画再生ソフトウェアやブラウザのアドオン等にバッファリング制御の一部として搭載 することで，ストリーミング方式の QoS を向上させることができると考えられる．従って， 本提案方式は有用性が高いことを示した． 5.6 今後の課題 今後の課題として，本提案方式の実装を行うにあたりソフトウェア側での処理時間を考慮 する必要があることが挙げられる．また，今回のシミュレーションではコンテンツ再生中は クライアントの受信ビットレートがコンテンツビットレートの上下 10 ％の値をランダムに 変化すると想定したが，実環境ではこの範囲以上のビットレートの変化が存在するため，そ の揺らぎも考慮に入れた制御を行わなければならない．懸念として，今回用いたコンテンツ データは MPEG-4 形式であったが，他の形式のコンテンツデータによっては問題が発生す る可能性がある．しかし，本提案方式ではコンテンツのビットレートと再生時間を基に事前 バッファリング時間を算出しているので，影響は少ないと考えられる． – 24 – 第6章 結論 6.1 まとめ 本稿ではインターネットの高速化とその普及に伴い，様々なコンテンツ配信サービスが提 供されている中で，コンテンツにおける操作性に優れたユニキャスト通信方式を用いたスト リーミング方式に着目した．ストリーミング方式における問題点として，コンテンツ再生が できなくなる再生断絶の発生が存在する．再生断絶はクライアントの受信帯域の低下によっ てパケット受信頻度が遅くなり，バッファ内にコンテンツデータが不足することよって発生 する．そこで，クライアントのバッファ制御とクライアントの受信帯域の測定に着目し，ス トリーミング方式を用いたコンテンツ再生において再生断絶を抑制する制御を提案した．提 案した制御方式では，クライアントが受信した RTP パケットの到着間隔を測定することで， 受信帯域の揺らぎを考慮したコンテンツ全体のバッファリングを行う時間（推定バッファリ ング時間）を推定する．推定バッファリング時間とコンテンツ再生時間との差分だけ再生前 にバッファリングを行うことで，コンテンツ再生中の再生断絶を抑制する．ストリーミング における QoS の基準が策定されていないため，本稿ではコンテンツ再生時の再生断絶の発 生率を QoS の基準として用いて本提案方式の有用性を検証した．検証にはネットワークシ ミュレータ「NS-3」を用いた．コンテンツとして，ビットレートが 2,300Kbps の再生時間 が 5 分及び 120 分の二種類を用いた．検証時のクライアントの受信帯域として，コンテンツ ビットレートの上下 10 ％の範囲をランダムに遷移する環境を用意した．シミュレーション 結果から，両コンテンツ共に再生時間の 5 ％未満の事前バッファリング時間で既存の方式で の再生時と比較して断絶発生率を 99 ％以上抑制できることが判明した．本提案方式の事前 – 25 – 6.1 まとめ バッファリング時間算出方法はコンテンツの再生時間に比例して待機時間も増大する．検証 結果より 120 分のコンテンツにおいて，再生時間の 5 ％未満の事前バッファリング時間で断 絶発生率を 99 ％以上抑制することができたため，120 分以内のコンテンツであれば，同様の 効果を得ることができると考えられる．従って，本提案方式の有効性が高いことを示した． – 26 – 謝辞 本論文を完成させるにあたり，指導教員である高知工科大学 情報学群の島村和典教授に は，丁寧かつ熱心な御指導を賜りました．また，研究活動だけではなく，就職活動や社会勉 強において的確かつ丁寧な御指導をしていただきました．ここに感謝の意を表しますと共に 深く御礼を申し上げます．また，本研究の副査を引き受けていただいた情報学群の吉田真一 准教授，ならびに植田和憲 講師には様々な御指導・御助言を頂き，心より感謝を申し上げま す．研究活動において様々な御指導・御助言をいただきました島村研究室 修士 2 年の山下 寛晃氏，和田倫弥氏に感謝致します．研究の進行状況に関して暖かく見守っていただいた島 村研究室 修士 1 年の小笠原一聡氏，京極海氏，島田裕幸氏，辻際宗和氏に感謝致します．研 究室の同輩として，共に研究活動に励み，苦楽を共にしてきた学士 4 年の赤澤将太氏，柏木 恵氏，品川滉樹氏，竹本万里雄氏，西本優介氏，野島舞氏に感謝致します．研究室の後輩と して，研究室活動に励んだ学士 3 年の國和武司氏，仙波紗和氏，中島春菜氏，三角隆太氏， 吉本圭佑氏，和田幸大氏に感謝致します. また，無理を言って大学に進学させて下さった両 親に，心より感謝申し上げます. 最後に，これまで私を支えて下さった家族，情報学群の皆 様に感謝の意を持って謝辞とさせていただきます. – 27 – 参考文献 [1] 総 務 省, ”平 成 25 年 度 版 イ ン タ ー ネ ッ ト の 利 用 動 向”, http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h25/html/nc243120.html, 2014 年 2 月 2 日. [2] 大楠大志，島村和典，村田正幸，”再生断続の無い Unicast Streaming のためのバッ ファリング管理方式の研究”，平成 24 年度学士学位論文. [3] 藤本康平，阿多信吾，村田正幸，”インターネットにおける実測に基づいたパケット転 送遅延の統計的分析”，平成 12 年 7 月度電子情報通信学会 信学技法 pp.41-47. [4] http://gigaom.com/2012/11/09/online-viewers-start-leaving-if-video-doesnt-playin-2-seconds-says-study/ , 平成 26 年 2 月 2 日. [5] http://www.nsnam.org/doxygen-release/index.html, 平成 26 年 2 月 2 日 – 28 –