成蹊大学理工学研究報告
J. Fac. Sci. Tech., Seikei Univ.
Vol.42 No.2 (2005) pp.7-17

品質劣化予兆検出に基づくストリーミング配信サービス品質劣化
回避制御方式栗林

伸一＊1，田邉 正雄＊2

Method of preventing the perceptual video quality deterioration in streaming media distribution
services based on the detection of deterioration sign
Shin-ichi KURIBAYASHI＊1，Masao TANABE＊2
ABSTRACT : To support the high quality streaming media distribution services, it is important to detect asign of perceptual video quality deterioration and to prevent the deterioration.
This paper proposes thealternative routing method to prevent the deterioration of TCP base streaming flow over the fault route.
First, this paper proposes to use the estimated number of packets stored for the reproduction in client PC
as a sign of the deterioration for TCP based streaming media distribution, and to detect the fault route.
Next, this paper proposes the method to automatically understand network topology and bandwidth usage
by monitoring BGP (Border Gateway Protocol) routing protocol packets, and to prevent the deteriorationof streaming flow over the fault route with alternative routing. The effectiveness of the proposed method isdemonstrated by simulation.
Keywords : Streaming media, perceptual video quality, quality control(Received August 18, 2005)
るシステム（SQM）を提案し，実システムへの適用によ

１．まえがきりその有効性を明らかにしている。しかし，これらの方ＡＤＳＬ，光ファイバ等の高速アクセス網の普及に伴式はいずれもサービス品質劣化の発生を把握または推定い，インターネット上でのストリーミング配信サービス

できるが，その予兆を検出して品質劣化を事前に回避すが普及してきている。今後は映像レートの高速化やＩＰることはできない。高品質なストリーミング配信サービ

放送の本格導入などが想定され，サービス品質の維持がスを提供するためには，サービス品質が劣化する前にそサービス提供上ますます重要になってくると考えられるの予兆を検出し劣化そのものを回避することが重要である。

。また，企業通信に対しては，ファイアウォールをストリーミング配信を対象に，品質劣化の予兆を検出通過できるＴＣＰ（ＨＴＴＰ）ベースのストリーミング

する方策は文献[3]，[7]などで提案されている。これらは配信を前提とする必要がある。

ＵＤＰベースのストリーミング配信を前提に，転送パケ

１），２）

従来，ストリーミング配信のサービス品質（ユーザ体

ット数などの変化により予兆を検出するものであり，Ｔ感品質）を把握する方法として，①ログ収集，②クライ

ＣＰベースのストリーミング配信を前提としたものでは

アント品質モニタ，③サーバ制御情報利用，④試験パケない。また，品質劣化を回避する制御方式として具体的

ット品質測定，⑤サーバ送出パケット変動測定，等が提な提案は行われていない。一方，文献[8]，[9]などはＴＣ。文献[5]，[6]では，外付け装置を網Ｐベースのストリーミング配信を対象に，クライアント内に設置し，既存の配信サーバやクライアント端末に影

端末内バッファに蓄積されている再生用パケット量を一

響なく，ユーザ毎の視聴品質をリアルタイムに監視でき定に保つように送信レートを動的に制御する方式
（以後，

３），４）

案されている「送信レート制御」）を提案している。これらはもともと＊1＊2

品質劣化の予兆検出を目的とした提案ではないが，結果：成蹊大学理工学部情報科学科教授 (Professor, Dept. ofComputer and Information Science, e-mail:として再生用パケット量が一定値以上確保されることか

kuribayashi@st.seikei.ac.jp)

ら品質劣化が起こらないように事前制御していると考え：ＮＴＴ情報流通プラットフォーム研究所主任研究員−7−

２．前提条件

ることができる。
しかし，分散制御を前提とする送信レート制御だけでは，以下のようなケースに対応できないため何らかの対

本稿で前提とするサービス条件，システム条件を以下策が必要となる。

に示す。

ａ）経路障害時には，ストリーミング配信パケットの

１）企業通信への適用を想定し，ＴＣＰベースのストリ

送信そのものができないため品質劣化が発生する。

ーミング配信サービスを前提とする。

ｂ）複数の配信フローが同時に送信レートを上げると

２）ＡＳ（Autonomous System）間ならびに各ＡＳ内では輻輳を誘発しかねない。また，何らかの総量制限をストリーミング配信サービスのために一定の帯域が確しないと，輻輳が継続しレートを上げられないため保され，データなどの他トラヒックと干渉しないことに端末内の再生用パケットが枯渇しかねない。

を前提とする。但し，ストリーミング配信サービス用ｃ）送信レートを動的に変更する機能を持っていない

帯域を複数のストリーミング配信フローで共用し，ス

既存サーバやクライアント端末には対応できない。

トリーミング配信フロー間での干渉は発生するものと文献[10]は，エンドツーエンド型の受信情報とネットする。

ワーク情報の両方を総合的に判断する送信レート制御方３）配信サーバはデータセンタなどに集中設置されるも式を提案しているが（但し，ＵＤＰベース），上記のケーのとする。

スａ），ｃ）に対応することはできないと考えられる。

４）ストリーミング配信フローは優先フローと非優先フ

そこで，本稿ではＴＣＰベースのストリーミング配信

ローに分類され， ＩＰヘッダ内のＴＯＳ値（本論文でを対象に，既存サーバやクライアント端末に影響を与えはＴＯＳ12）とＤＳＣＰ12) の両方を示すものとして使ることなく，障害経路を通っていたストリーミング配信用）によって区別する。配信開始時点からそれぞれにフローを品質劣化させずに迂回させる迂回制御方式を提対応したＴＯＳ値を全パケットに設定する。ネットワ

案する。品質劣化を回避するためには，図１に示すようーク内の各ルータはＴＯＳ値に基づく優先転送機能をにまず品質劣化の予兆を検出し，次に劣化原因・箇所を具備し，優先フローパケットを非優先フローパケット

特定し，最後に劣化回避制御を実施する必要がある。まよりも優先して転送するものとする。

ず，２章では検討の前提条件を述べる。３章では，品質

５）各ＡＳは，ＡＳ間でやりとりさせるストリーミング

劣化の予兆を検出する方法を明らかにする。４章では，配信フローの流量の総和をＴＯＳ値毎に実測するもの

障害経路を特定する方法を明らかにする。さらに，障害とする。

経路を経由して転送していた配信フローを品質劣化させ３．品質劣化の予兆検出法

ることなく迂回させるための迂回制御アルゴリズム，ならびにそれを実現するためのシステム構成を提案する。
５章は実機を用いたシミュレーションにより，４章で提ＴＣＰによるストリーミング配信では，輻輳などによ案した迂回制御方式の有効性を定量的に評価する。６章

りパケット損失が発生するとＴＣＰフロー制御によりスはむすびである。

ループット自体が低下する。この状態が長く続くとクライアント端末内の再生用パケットが徐々になくなる。再生用パケット量が一定値（Ｙ秒分）以下になると，再生＜ステップ１＞

品質劣化の予兆を停止し再生用パケットの蓄積を図る（パケット量がＺ

検出

秒分まで回復したら再生を再開），
または映像レート自体を落とす，などの対策が一般に用いられる。この再生を＜ステップ２＞

停止した時点または映像レートを落とした時点で 品質

品質劣化の原因・箇所の特定

劣化 状態になったと考えられる（図２）。したがって，
品質劣化を防ぐためには，再生用パケット量が Y 秒以下にならないようにする必要がある。

＜ステップ３＞

これを踏まえ，文献［8］と同じように，クライアント

品質劣化の事前回避制御

端末内バッファに蓄積されている再生用パケット量を監視し，その量が一定値以下になった時点で 品質劣化予

図１ 品質劣化を事前に回避するための処理ステップ

兆 と判断して劣化回避制御を起動する（図３）
。なお，

−8−

t

＜ケース１＞

Ｗ（ｔ）＝Ｘ＋∫ { ｖ（ｔ）−ｕ }ｄｔ

再生用パケット量W (t)0

これを下回ると再生を停止(バッファの蓄積を行う)。

Ｘ秒分
Ｚ秒分

これを上回ると再生再開(2) 品質劣化予兆の判断式（１）により推定したＷ(ｔ)が●Ｗ（ｔ）＜Ｗ０

●

Ｙ秒分

(1)

(2)

となった時点（ｔ＝ｔ0）で劣化予兆とみなす。Ｗ０は，品質劣化状態

時間 ｔ

ｔ０＋T

再生用パケット量W (t)＜ケース２＞{Ｗ０−Y}＞∫

T×{ｕ−ｖ（ｔ）}ｄｔ

(3)

ｔ０

Ｘ秒分
これを下回ると映像レートを低下させて再生継続を満足する T［秒］以内に劣化原因・箇所の特定，劣化
回避制御，

●

Ｙ秒分

ｖ（ｔ）＞ｕ状態への移行，を達成できるように決定する。
品質劣化状態

時間 ｔ

図２ クライアント端末内再生用パケット量の推移（ 劣化回避制御なし の場合）

４．障害経路の特定と品質劣化を回避する迂回制御方式
経路障害発生時にどれだけのストリーミング配信フロ
ーを迂回先経路に迂回できるか判断するためには，ネッ

再生用パケット量W (t)W (t=0)

トワークトポロジ（ＡＳ間の経路）と各経路における帯
域利用状況を把握しておく必要があり，これを４.１節で劣化回避制御の起動Ｘ秒分説明する。また，障害経路の特定が必要であり，４.２節で説明する。さらに，障害経路を経由して転送していた

●

閾値Ｗ0

配信フローを品質劣化させずに迂回させるための迂回制

映像停止または映像レ●

Ｙ秒分

ート低下なし御アルゴリズムが必要であり，４.３節で提案する。

ｔ０
ｔ=0
Ｔ

時間 ｔ

4．1 ネットワークトポロジと各経路の帯域利用状況把握法＜ケース１，２に共通＞

ルーティングプロトコルＢＧＰ13)の更新（Update）パ

図３ クライアント端末内再生用パケット量の推移（ 劣化回避制御あり の場合）

ケットをモニタリングすることにより，ＡＳ間経路と各経路の帯域利用状況を自動的に把握する方式を提案する。
まず，更新メッセージ内の「ＡＳ-PATH Attributes」か

文献[8]は劣化回避制御として，送信レートを増加させて

らＡＳ経路，「Network Layer Reach-ability Information フィいると考えることができる。
具体的な品質劣化予兆の検出手順を以下に示す。

ールド」 からネットワークアドレスを抽出し，ネットワ＜手順１＞クライアント端末内の再生用パケット量の推ークトポロジ（ＡＳ間経路）やクライアントアドレスを定把握する。これは既存機能で実現可能である。次に，パ
網内で各ストリーミング配信のＴＣＰフローをリアルス属性として ＡＳ間帯域 を新たに規定し，これを BGP

タイムに監視する。そして，各クライアント端末に正し更新メッセージに格納して通知する。但し，帯域変更毎く到着するパケット量ｖ（ｔ）〔ビット／秒〕を算出し（再に更新メッセージを送信すると処理負荷が大きくなるた

送分はカウントしない），
各クライアント端末内バッファ

め，一定周期または帯域がある閾値を超えた時点で更新に蓄積される再生用パケット量Ｗ(ｔ)〔ビット〕を以下メッセージを生成しＡＳ間帯域を通知するものとする。

の式により推定する。但し，ｔは時間，ｕ〔ビット／秒〕

ＡＳ間帯域は隣接ＡＳ間毎に以下の６つのパラメータは再生レート，Ｘ〔ビット〕は初期バッファ量(Ｗ(t=0) )を含む。なお，ＡＳ間の帯域はＡＳ間物理回線だけを対とする。

象としたものでなく，ＡＳ内で経由する経路も含めたも−9−のとする。また，ＡＳ番号が小さいＡＳから大きいＡＳ

・ｋ６：隣接ＡＳ間で非優先フローが利用している帯の方向を「上り」，その逆方向を「下り」とする。

域（上り方向）＜新パス属性「ＡＳ間帯域」が含むパラメータ＞

パス属性 ＡＳ間帯域 の通知イメージを図４，ＢＧ

・ｋ１：隣接ＡＳ間で利用可能な空き帯域（上り方向）

Ｐ更新メッセージ内のＡＳ間帯域フォーマット案を示す

・ｋ２：隣接ＡＳ間の利用可能な空き帯域（下り方向）

図５に示す。図４では，ＡＳ１からＡＳ５までに経由す・ｋ３：隣接ＡＳ間で優先フローが利用している帯域

るＡＳ番号を含むＡＳパス属性と共に，ルート上の隣接（上り方向）

ＡＳ間帯域情報リストが伝えられることを示している。

・ｋ４：隣接ＡＳ間で優先フローが利用している帯域

この例ではＡＳ１−ＡＳ５間の経路としてはＡＳ１−Ａ（下り方向）

Ｓ３−ＡＳ５とＡＳ１−ＡＳ２−ＡＳ４−ＡＳ５の２つ

・ｋ５：隣接ＡＳ間で非優先フローが利用している帯が利用可能であり，それぞれの経路の利用可能帯域を知域（上り方向）ることができる。
0

16

31

ネットワーク
1.0.0.0/8

①

マーカ

ＡＳ１

②

ＡＳ３

配信サーバ
長さ

クライアント
端末

③

ＡＳ５

タイプ

使用不能ルート長

取り消しルート

取り消しルート続き

ＡＳ２

パス属性全長

⑤

ＡＳ４

パス属性

パス属性続き④

ネットワーク到達可能性情報

AS：Autonomous System

BASｘ-ASｙ ：ASｘとASｙ間の帯域{ｋ１〜ｋ６}●ＢＧＰ更新パケットの内容＜①＞パス属性

新規パス属性「ＡＳ間帯域」

ＡＳパス属性：ＡＳ１，ＡＳ間帯域属性：ＢＡＳ3‑ＡＳ１
ネットワーク層到達可能性情報 1.0.0.0/8＜②＞パス属性
ＡＳパス属性：ＡＳ３

１バイト １バイト ２バイト １バイト ３バイト

ＡＳ１，ＡＳ間帯域属性：ＢＡＳ４‑AS2

ＡＳ２

〜

パラメータ

Ｋ６

属性タイプコード：「AS間帯域」に含まれる６つのパラメータ１８（オプション）・ｋ1：隣接AS間で利用可能な空き帯域〔ｋビット/秒〕（上り方向）
ＢＡＳ２‑AS1

ネットワーク層到達可能性情報 1.0.0.0/8＜⑤＞パス属性
ＡＳパス属性：ＡＳ４

Ｋ１

属性フラグ：４０

ＡＳパス属性：ＡＳ１，ＡＳ間帯域属性：ＢＡＳ2‑AS1
ネットワーク層到達可能性情報 1.0.0.0/8＜④＞パス属性
ＡＳパス属性：ＡＳ２

データ パラメータ
長

ＡＳ１，ＡＳ間帯域属性：ＢＡＳ５‑ＡＳ３ ＢＡＳ３‑AS1

ネットワーク層到達可能性情報 1.0.0.0/8＜③＞パス属性

１バイト ３バイト

・ｋ2：隣接AS間で利用可能な空き帯域〔ｋビット/秒〕（下り方向）
・ｋ3：隣接AS間で優先フローが利用している帯域〔ｋビット/秒〕（上り方向）
・ｋ4：隣接AS間で優先フローが利用している帯域〔ｋビット/秒〕（下り方向）

ＡＳ１，ＡＳ間帯域属性：ＢＡＳ5‑AS4
ＢＡＳ４‑AS2, ＢＡＳ２‑AS1

・ｋ5：隣接AS間で非優先フローが利用している帯域〔ｋビット/秒〕（上り方向）

ネットワーク層到達可能性情報 1.0.0.0/8

・ｋ6：隣接AS間で非優先フローが利用している帯域〔ｋビット/秒〕（上り方向）【注】AS間帯域はAS間物理回線だけでなく，以下のようにAS内部も考慮した帯域である．

図５ ＢＧＰ更新メッセージに含む新規パス属性［ＡＳ間帯域］
フォーマットＢＡＳｘ‑ＡＳｙ は<1>と<2>を比べて小さい方を通知

ASｘ
ルータ

＜１＞

A

ASｙ

A

4．2 障害経路の特定化手順＜２＞

図６の例では，以下のように障害箇所を特定化するこ

ルータとができる。但し，ここでは２重障害は想定しない。
まず，
図６の中で(1)が障害ならば端末ｄも品質劣化す
図４ ＢＧＰ更新メッセージを利用したAS間帯域の通知イメージ

るはずであるが劣化していないため(1)ではない。
同様に，(2)が障害なら端末ｂは品質劣化しないはずであり，(2)ではない。
(5)が障害なら端末ａや端末ｄの品質も劣化す
るはずであり，(5)ではない。(6)が障害なら端末ａの品
質も劣化するはずであり，(6)ではない。(7)が障害なら端末ｄの品質も劣化するはずであり，(7)ではない。以上−10−

から，(3)または(4)の障害が原因と推定できる。

障害箇所
端末ｘの品質劣化予兆検出

これを一般化した「障害箇所の特定化フロー」を図７①に示す。図７(1)はネットワーク構成，図７(2)は障害箇
端末ｘが接続されている配信サーバＡに接続されている全端末（端末ｘが収容されているＡ
Ｓだけでなく全ＡＳ内の端末が対象）の多くで品質劣化予兆あり所の特定化フローを示す。図７はネットワーク経路だけ
でなく，配信サーバの障害も含めた障害箇所の特定を前提とし，以下の考え方に基づいている。

Ｙｅｓ 配信サーバＡまたは配信サーバＡ−ＡＳ１間回線の障害と推定

Ｎｏ

１）品質劣化しやすく，かつ障害時の影響範囲が大き

配信サーバＡが収容されているＡＳ１とそれよりも下流の全ＡＳに収容されている端末の多
くで品質劣化予兆あり

い順，つまり配信サーバ，ネットワークの順に障害②
Ｙｅｓ ＡＳ１の障害と推定を切り分けていく。
Ｎｏ

品質劣化

品質劣化

端末ｂ

端末ｃ

端末ａ

(4)

ＡＳ
＃２

(7)
サーバ＃２

端末ｄ

(3)

(5)
AS
＃１

Ｙｅｓ ＡＳ2−ＡＳ3間回線またはＡＳ
３の障害と推定

Ｎｏ

(1)

(2)

２の障害と推定④

ＡＳ２より１つ下流のＡＳ３とＡＳ３よりも下流の全ＡＳに収容されている端末の多くで品質劣化予兆あり

・
・
・
・

(6)

Ｙｅｓ ＡＳ1−ＡＳ2間回線またはＡＳ

Ｎｏ

経路
障害
サーバ＃１

③

ＡＳ１より１つ下流のＡＳ２とＡＳ２よりも下流の全ＡＳに収容されている端末の多くで品質劣化予兆ありＡＳ＃４

端末ｘ１を収容するASJになるまで繰り返す

ＡＳJとＡＳJよりも下流の全ＡＳに収容されている端末の多くで品質劣化予兆あり⑤

Ｙｅｓ ＡＳ(J-1)−ＡＳJ間回線またはASJの障害と推定⑥

Ｎｏ

端末ｘまたは端末ｘとASJ間回線の障害と推定

ＡＳ＃３注）２重障害は想定しない。

(2) 障害箇所の特定化フロー

図６ 障害箇所の特定化の例

図７ 障害箇所の特定化フロー (2/2)
２）ネットワークでは，配信サーバに近いＡＳ（上流）

品質劣化
予兆 検出

⑥

から障害を切り分けていく。これは，障害ＡＳの下

端末ｘ

流のすべてのＡＳに収容されている端末の品質が劣

端末
端末

④

配信サーバＡ①②③

化するため，上流ほど障害時の影響範囲が大きいこ⑤

端末

ＡＳ(J+1)

ＡＳJとが理由である。
4．3 品質劣化を回避する迂回制御アルゴリズム
本節では，経路障害時に 障害経路を経由して転送さＡＳ３れていた配信フロー を品質劣化させずに迂回させるた

ＡＳ２めの迂回制御アルゴリズムを提案する。なお，文献[14]ＡＳ1〜[16]などは品質劣化後の劣化回復を目的とした制御方
ＡＳ(m+1)式を提案しており，ここではそれらを参考にする。

配信サーバＢ

4．3．1 前提条件

ＡＳm１）２重障害は想定しない。また，迂回先経路は１つと(1) ネットワーク構成図する。

図７ 障害箇所の特定化フロー（1/2）

２）障害経路（Ｐ）を通っていた優先フローは，迂回先
経路（Ｑ）の空き帯域と経路Ｑを通っている非優先フ
ローが利用している帯域を合わせた帯域分まで迂回させる。つまり，経路Ｐを通っていた優先フローを経路−11−

Ｑの空き帯域だけで収容できない場合には，経路Ｑを

この時にどの配信フローをどれだけ迂回させるかを図通っていた非優先フローの帯域を使って収容する（こ８のモデルを使って以下に説明する。

の場合，非優先フローの品質は劣化する）。なお，それでも経路Ｐを通っていた優先フローを全て迂回できな
障害経路（P)

い場合は，迂回できない優先フローに対応したパケッ＜上り方向帯域＞＜下り方向帯域＞

ｋ3(P)＋ｋ5(P)ｋ4(P)＋ｋ6(P)迂回

トは廃棄する（この場合，迂回できない優先フローの使用中

品質は劣化する）。
３）経路Ｐを通っていた非優先フローは，経路Ｐを通っ

空き帯域

ｋ1(Q）

ｋ2(Q）

ていた優先フローを全て経路Ｑに迂回させても空き帯

使用中

ｋ3(Q)＋ｋ5(Q)ｋ4(Q)＋ｋ6(Q)域が残っていればその分だけ迂回させる。迂回できな
迂回経路（Q)

い非優先フローのパケットは廃棄する（この場合，迂全ての目的ＡＳ向け配信フローが利用する経路

回できない非優先フローの品質は劣化する）。

＊障害経路を通して転送されていた配信フローは，目的ＡＳに関係なく全て経路Q（物理的には複数のノード，回線を経由していることもある）を迂回して転送される。

４）経路Ｐを通っていた配信フローには，目的ＡＳが異なる配信フローが混在している。そのため，帯域制限＜ケース１＞ 迂回経路が１つの経路から構成される場合

から経路Ｑに全ての配信フローを迂回できない場合，
もともと経路Ｐを流れていた目的ＡＳ別配信フローの量に比例して迂回させるものとする。さらに，これは障害経路（P)

優先フローと非優先フロー別々に算出する。

迂回使用中

５）上記２）〜４）を実現するために経路Ｐと経路Ｑ両方の経路のｋ１値〜ｋ６値（４.１節で規定）を利用す空き帯域る。
６）配信サーバにおける送信レートは一定とする。
但し，

空き帯域
空き帯域

使用中

使用中

輻輳によるパケット廃棄や配信サーバ内の送信バッフ
経路（Q１)

ァ満杯などによりクライアント端末が受信するレートは変動する。

経路（Q２)・・・
使用中
経路（Qn)

目的ＡＳｘ向け配信フローが利用する経路
目的ＡＳｙ向け配信フローが利用する経路

・・

4．3．2 迂回制御アルゴリズムの提案(1) 手順１

目的ＡＳｚ向け配信フローが利用する経路

４.１節の手順に従い収集したＡＳ間経路と各経路で＊障害経路Ｐを通して転送されていた配信フローが全て経路Qnまで使用して迂回されるわけではなく，目的ＡＳ毎にＱ２まで，Ｑ
３までというように決まる。

利用可能な帯域情報をもとに，各経路毎に予め迂回経路を選択しておく。

＜ケース２＞ 迂回経路が複数の経路から構成される場合(2) 手順２

図８ 経路障害時の迂回制御アルゴリズムの説明図

３章で述べた手順に従って，クライアント端末内の再生用パケット量を監視することにより品質劣化予兆を検出し，４.２節で提案した手順に従って障害経路を＜迂回フローの算出アルゴリズム＞

特定する。

【I】迂回経路が１つの経路から構成される場合（図８の(3) 手順３

ケース１に対応）

ＢＧＰプロトコルによる障害通知は時間がかかり，以下の分析を上り方向，下り方向で別々に行い，迂回それを期待しているとその間に再生用パケットがクラできる配信フローのトータル量が多くなる方向の結果を

イアント端末に届かず結果として再生用パケットが枯採用する。なお，ｋｊ（Ｑ）は迂回経路Ｑのｋｊ値（ｊ渇してしまう。そのため，経路障害時にＢＧＰによる＝１〜６），ｋｊ（Ｐ）は障害経路Ｐのｋｊ値（ｊ＝１〜

新経路確立を待つのではなく，予め経路毎に決められ６）を示すものとする。

た迂回経路で転送するポリシールーティングを採用す

１）上り方向の分析る。品質劣化予兆を検出した直後に，ポリシールーテ

・ｋ１（Ｑ）＞ｋ３（Ｐ）ならば，経路Ｐを流れていた

ィングを用いて障害経路を通っていた配信フローパケ

全ての優先フローを経路Ｑに迂回。経路Ｐを流れていたットを迂回経路を通して転送する。

{ｋ１(Ｑ)−ｋ３（Ｐ）}分の非優先フローを経路Ｑに迂−12−回させる。経路Ｐを流れていた残り｛ｋ５（Ｐ）−

２）下り方向の分析（ｋ１（Ｑ）−ｋ３（Ｐ））｝分（この値が負になる場合は・ｋ２（Ｑ）＞ｋ４（Ｐ）ならば，経路Ｐを流れていた

残り０とみなす）の非優先フローのパケットは廃棄する。

全ての優先フローを経路Ｑに迂回。経路Ｐを流れていた・｛ｋ１（Ｑ）＋ｋ５（Ｑ）｝≧ ｋ３（Ｐ）≧ｋ１（Ｑ）｛ｋ２（Ｑ）−ｋ４（Ｐ）｝分の非優先フローを経路Ｑにならば，経路Ｐを流れていた全ての優先フローは経路Ｑ

迂回させる。経路 P を流れていた残り｛ｋ６（Ｐ）−に迂回させる。経路Ｐを流れていた全ての非優先フロー（ｋ２（Ｑ）−ｋ４（Ｐ））｝分（この値が負になる場合はのパケットは廃棄する。

残り０とみなす）の非優先フローのパケットは廃棄する。

・ｋ３（Ｐ） ＞ {ｋ１（Ｑ）＋ｋ５（Ｑ）} ならば，・｛ｋ２（Ｑ）＋ｋ６（Ｑ）｝≧ ｋ４（Ｐ）≧ｋ２（Ｑ）｛ｋ３（Ｐ）−（ｋ１（Ｑ）＋ｋ５（Ｑ））｝分の優先フロ

ならば，経路Ｐを流れていた全ての優先フローは経路Ｑ

ーを経路Ｑに迂回させる。経路Ｐを流れていた残りの優に迂回させる。経路Ｐを流れていた全ての非優先フロー

先フロー，経路Ｐおよび経路Ｑを流れていた全ての非優のパケットは廃棄する。

先フロー，に対応するパケットを廃棄する。

・ｋ４（Ｐ）＞｛ｋ２（Ｑ）＋ｋ６（Ｑ）｝ならば，・障害経路Ｐを通っていた配信フローには，目的ＡＳが｛ｋ４（Ｐ）−（ｋ２（Ｑ）＋ｋ６（Ｑ））｝分の優先

異なる配信フローが混在している。そのため，迂回経路

フローを経路Ｑに迂回させる。経路Ｐを流れていた残りＱに全ての配信フローを迂回できない場合，もともと経の優先フロー，経路Ｐおよび経路Ｑを流れていた全ての路Ｐを流れていた 目的ＡＳ別配信フローの量に比例

非優先フロー，に対応するパケットを廃棄する。

して迂回させるものとする（図９（１）に一例を示す）。

・迂回経路Ｑに全ての配信フローを迂回できない場合のさらに，これは優先フローと非優先フロー別々に算出す

対処は上り方向と同じである。

る。

【II】迂回経路が複数の経路から構成される場合（図８のケース２に対応）
AS1

a
b

障害

AS2

もっとも下流の（配信サーバから遠い）経路Ｑn から

AS3

順次上記【I】で示したアルゴリズムに従って転送可能な
配信フローの量を算出し，上流の経路Ｑ(n-1)における転

迂回

a

AS4

送可能配信フローの量の算出に反映させる。例えば，経最大 -----×ｍ だけ迂回可
a＋b

路Ｑ(n-1)だけを対象に上記【I】に従って算出した転送可ｂ

能フロー量がＦ１となった場合，これが経路Ｑｎで転送

最大 -----×ｍ だけ迂回可
a＋b

可能なフロー量Ｆ２に比べて大きい時には経路Ｑｎを通ａ：AS2向け配信フローの量，ｂ：AS3向け配信フローの量
ｍ：AS1àAS4àAS2の利用可能帯域

る配信フローの最大をＦ２に制限し，その差分（Ｆ１−

障害経路を流れていた場合と同じ比率で迂回できる場合

ることになる。
逆に，
Ｆ２がＦ１に比べて大きい場合は，

(1)

AS1

a
b

障害

AS2

Ｆ２）を経路Ｑｎを利用しない配信フロー用に振り分け

AS3

Ｑｎを流れる最大配信フロー量はＦ１となる（図９(2)に一例を示す）。
同じ手順を迂回経路の最上流経路Ｑ１になるまで繰りAS4返すことにより，どの目的ＡＳ向け配信フローをどこま

迂回で転送することができるか決定できる。なお，【II】のケｎ1 ：AS1àAS4àAS3の利用可能帯域
ｎ2 ：AS3àAS2の利用可能帯域

ースでは，下流の経路に帯域制限があるために上流の経a-----×ｎ1
a＋b＞ ｎ2

AS1àAS2àAS3配信フローは最大＜参考＞b-----×ｎ1a＋b路の帯域が空いているにもかかわらず有効に使われないならば，AS1àAS2配信フローは最大ｎ2だけ迂回させ，（ｎ１−ｎ２）ことが起こり得る。

だけ迂回可能となる。

4．3．3 制御システム構成＜ （ｎ1−ｎ2）

４.３.２節で提案した迂回制御アルゴリズムを実現するためのシステム構成を図 10 に示す。具体的には，配信(2) 障害経路を流れていた場合と同じ比率で迂回できない場合

フロー毎にＴＣＰフローをリアルタイムに監視し品質劣

図９ 迂回時の配信フロー振り分け比率の考え方

化予兆を検出する「品質監視装置」，ＡＳ間経路と各経路の帯域利用状況を把握するための「ネットワークトポロ
ジ解析装置」，迂回できない配信フローのパケットを−13−

クライアント端末 クライアント端末
（優先）
（非優先）
＃４
＃５

クライアント端末

AS101
配信
サーバ

レート制御装置
クライアント端末

障害

AS102

品質監視 ネットワーク
トポロジ解析
装置
装置

ルータ

AS101

●

AS104

●

クライアント端末
︵優先︶

ルータ

配信
サーバ

レート制御装置

ルータ

ルータ

＃１

AS102

AS103

●

ルータ

迂回

AS104

●

＃２
＃３

AS103

＜外付け装置の機能＞・「ネットワークトポロジ解析装置」：ＢＧP更新メッセージをリアルタイムに

品質監視装置モニタリングし，AS間経路と各経路の帯域利用状況を抽出。
・「品質監視装置」：配信サーバとクライアント端末間のTCPフローをモニタリ

ネットワーク
トポロジ解析
装置

クライアント端末（非優先）

ングし，各クライアント端末内の再生用パケット量を推定。

図11 シミュレーションで用いたネットワーク構成

・「レート制御装置」：経路障害時に，障害経路を通して転送していた配信フ
ローで迂回できない配信フローのパケットを選択廃棄。

図10 迂回制御方式を実現するためのシステム構成(2) 映像配信はＭＰＥＧ４，制御プロトコルはＲＴＳＰ
17)を前提とする。映像レートは１Ｍビット／秒の固定廃棄する「レート制御装置」を，配信サーバが設置されレートとする。

ているＡＳ内に設置する。既存配信サーバ，ネットワー(3) 配信サーバ，ルータ，クライアント端末は全て実機

ク装置ならびにクライアント端末への影響をなくすため，を使用する。各ルータは e‑BGP を起動し，ホールドタ

これら装置は外付け装置の形態で設置する。

イマは 12 秒に設定する。

また，レート制御装置への動作指示ならびに該当ルー

品質監視装置，ネットワークトポロジ解析装置，レ

タへのポリシールーティング起動指示は，ネットワーク

ート制御装置はそれぞれパソコンで実現する。

トポロジ解析装置が行うものとする。

(4) 各クラインアント端末内で再生開始前に蓄積するパケットは５秒分（Ｘに対応），品質劣化予兆と判断する

５．シミュレーション評価

再生用パケット量は 3.5 秒分（Ｗ０に対応），品質劣化と判断する再生用パケット量は 2.5 秒分（Ｙに対応）

本章では，４章で提案した迂回制御アルゴリズムの有とする。これらは全クライアント端末で共通とする。

効性を実機を使ったシミュレーションにより評価する。

(5) 配信サーバならびにクライアント端末のＴＣＰ最大ウインドウサイズは 65,535 バイト，
１パケットサイズ

5．1 前提条件は最大 1,500 バイトとする。

(1) シミュレーションで用いるネットワーク構成を図(6) 障害発生前のＡＳ間帯域として以下を想定する。な11 に示す。配信サーバ，ネットワークトポロジ解析装

お，単位は全て〔ビット／秒〕。

置，品質監視装置，レート制御装置はＡＳ１０１に設・ＡＳ１０１−ＡＳ１０２間のＡＳ間帯域値置される。ＡＳ１０１に収容されている配信サーバか

ｋ１：１Ｍ，ｋ２：2.8Ｍ，ｋ３：１Ｍ，ｋ４：0.1Ｍ，

らＡＳ１０１àＡＳ１０２経由でＡＳ１０２に収容さ

ｋ５：１Ｍ，ｋ６：0.1Ｍ

れているクライアント端末＃４，＃５にストリーミン

・ＡＳ１０１−ＡＳ１０３間のＡＳ間帯域値

グ配信パケットを転送する。また，ＡＳ１０１‑àＡＳ

ｋ１：２Ｍ，ｋ２：4.8Ｍ，ｋ３：２Ｍ，ｋ４：0.1Ｍ，

１０３‑àＡＳ１０４経由でＡＳ１０４に収容されて

ｋ５：１Ｍ，ｋ６：0.1Ｍ

いるクライアント端末＃１，＃２，＃３にストリーミ

・ＡＳ１０３−ＡＳ１０４間のＡＳ間帯域値

ング配信パケットを転送する。
クライアント端末＃１，

ｋ１：0.5Ｍ，ｋ２：3.3Ｍ，ｋ３：２Ｍ，ｋ４：0.1Ｍ，＃２，＃４向けの配信フローを優先フロー，それ以外

ｋ５：１Ｍ，ｋ６：0.1Ｍのクライアント端末向け配信フローを非優先フローと・ＡＳ１０３−ＡＳ１０４間のＡＳ間帯域値する。

ｋ１：３Ｍ，ｋ２：３Ｍ，ｋ３：０Ｍ，ｋ４：０Ｍ，−14−

再生用バケット量w(t)[秒分]

ｋ５：０Ｍ，ｋ６：０Ｍ(7) ＡＳ１０２内の回線障害発生により，経路ＡＳ１０
１‑àＡＳ１０２が障害になるものとする。

55．2 シミュレーション結果と評価
４章で提案した迂回制御アルゴリズムを実施しない場

2.5

合の特性と実施した場合の特性をそれぞれ図 12〜図 14に示す。なお，スループットは配信サーバからクライア
ント端末に正しく届いた情報をビット／秒で表わしたも０のである（再送分は含まない）
。

０

５

10

15

時間ｔ[ 秒]BGP を用いた新経路（ＡＳ１０３経由）確立に 10 秒以上かかるため，迂回制御アルゴリズムを実施しない図 12(1) クライアント端末＃4(優先)内の再生用バケット量の例では障害経路を利用していた優先フロー（クライア
ント端末＃４向け）でも段々と再生用パケットがなくな
り劣化を回避できないことがわかる。

スループット図 13 では，障害経路を利用していた優先フロー（クライアント端末＃４）は障害発生後約 1 秒程度でポリシー
ルーティングにより新経路を経由して転送され，再生用

2.０

パケット量がＹ（＝2.5 秒分）を下回わらずにもとのレ
1.０

ベルＸ（＝５秒分）まで回復していることがわかる。図13(2)で，迂回制御実施後に急激にスループットが増加しているのは以下の理由によるものと考えられる。
つまり，

０
０

５

10

15

時間ｔ[ 秒]

配信サーバ内では障害によりパケットの転送がうまくできないため，ＴＣＰバッファ内にパケットが蓄積された(2) クライアント端末＃4(優先)フローのスループット状態になる。そして，迂回によりＴＣＰ転送が可能になった時点で蓄積されていたパケットが一気に送信される。

図 12 シミュレーション結果(迂回制御なし)

ところで，
経路ＡＳ１０１‑àＡＳ１０２の優先フロー（端末＃４向け）を経路ＡＳ１０１‑àＡＳ１０３‑àＡ

６．むすび

Ｓ１０４‑àＡＳ１０２に迂回させると，
経路ＡＳ１０３‑àＡＳ１０４間の帯域総計が物理帯域 3.5Ｍを超えることになる。しかし，もともと経路ＡＳ１０１‑àＡＳ１

本論文では，ＴＣＰベースのストリーミング配信を対

０３‑àＡＳ１０４で転送されていたクライアント端末

象に，クライアント端末内バッファに蓄積される再生用＃３向けパケット（非優先フロー）がレート制御装置でパケット量により品質劣化の予兆を検出し，品質劣化を

選択廃棄されることにより，クライアント端末＃４向け

事前に回避する迂回制御方式を提案した。具体的には，

パケット転送が確保され，結果としてクライアント端末

送信レートを動的に変更する従来方式では対応できない＃４内の再生用パケット数が一定値以下になることを防経路障害を対象に，複数のクライアント端末内再生用パいでいる。逆に，クライアント端末＃３向けのパケットケット量を分析することにより障害経路を特定し，その受信は減少し，結果として品質劣化してしまうことが図

障害経路を経由して転送していた配信フローを品質劣化

14(1)により理解できる。

させずに迂回させるための迂回制御アルゴリズムを提案

なお，クライアント端末＃５向けパケットは４.３.２

した。そのために，ＢＧＰプロトコルに隣接ＡＳ間の帯節で提案した迂回制御アルゴリズムに従い，レート制御

域利用状況を通知し合うためのパス属性 ＡＳ間帯域装置で廃棄される。

を新たに導入することを提案した。さらに，実機を用い以上から，４章で提案した迂回制御アルゴリズムは有たシミュレーションにより提案方式の有効性を明らかに効に機能し，経路障害時に優先フローの品質劣化を事前した。

に回避できることがわかる。

−15−

５
５
3.５
2.５
2.５

０

０
０

５

10

15

20

０

５

10

15

時間ｔ[ 秒]

時間ｔ[ 秒](1) クライアント端末＃4(優先)内の再生用バケット量(1) クライアント端末＃3(非優先)内の再生用バケット量

2.０
2.０

1.０

０
1.０

０

５

10

15

時間ｔ[ 秒]
０(2) クライアント端末＃3(非優先)フローのスループット
０

５

10

20

15

時間ｔ[ 秒]

図 14 シミュレーション結果(迂回制御あり)(2) クライアント端末＃4(優先)フローのスループット
ク，クライアント端末を個々にみるのではなく，システ

図 13 シミュレーション結果(迂回制御あり)

ム全体をみた真の原因特定を行う必要がある。例えば，
ネットワークが混み合っているからといって，ネットワ

今後の課題を以下に述べる。

ークの帯域を安易に大きくすると逆に配信サーバが混み

１）配信サーバが複数のＡＳに設置された場合，なら合って品質が劣化する可能性もある。この場合，ネット

びに迂回先経路が複数存在する場合の迂回制御アル

ワークに接続するストリーミング配信フローの数またはゴリズムの検討が必要である。

映像レートを削減する必要がある。

２）データサービス（Web アクセス，ファイル転送な

参考文献

ど）
や VoIP などと帯域を共用する形態での品質劣化
予兆検出技術と劣化事前回避アルゴリズムの確立が必要である。

[1] Zamora, J., Jacobs, S., Eleftheriadis, A., Chang, S. F. and３）数万加入以上の大規模システムにおいて，少ない

Anastassiou, D. ： A Practical methodology for

情報収集で効率良く障害箇所を特定化する方法の検guaranteeing quality of service for video-on-demand,討が必要である。

IEEE Trans. Circuit and Systems for Video Technology.,

４）品質劣化箇所として本論文では経路障害を対象と

Vol.10, No.1, pp.167-178 (2000)

した。実際のストリーミング配信サービスシステム[2] 岩崎量，間伸一，渡部 優，柳本 清，片山 頼

は，配信サーバ，ネットワーク，アクセス回線，ク

明：通信ネットワーク利用放送における視聴品質測ライアント端末など複数のコンポーネントから構成

定装置構成法の検討 ，情報処理学会全国大会原稿され，様々な障害ならびに輻輳を考慮した特定法の（2004.3）

検討が必要である。この場合，サーバ，ネットワー[3] 加藤 由花，佐々木 徹，箱崎 勝也：IP ネットワー−16−

クでの映像配信サービスを対象とした利用者指向[11] 永渕 幸雄，柳本清，森下 幸治，栗林 伸一：ス

QoS 制御手法の提案，情報処理学会論文誌 Vol.44,

トリーミング配信サービスにおける品質劣化検出方

No.3, pp.561-569 (2003)

式の提案，電子情報通信学会[4] 富永 聡子，中島 伊佐美：サーバ送出パケットを用

信学技報 IN2003-48(2003.7)

いた映像配信サービス品質管理法の検討，電子情報[12] RFC1349 (Type of service in the internet protocol suite),

通信学会 信学技報 NS2002−176 (2002.11)

RFC2474(Definition of the differentiated services field[5] Y. Nagafuchi, K. Yanagimoto, N. Takagi andin the IPv4 and IPv6 headers)S. Kuribayashi：Perceptual video quality management[13] RFC1771 (A border gateway protocol 4), RFC1966,

system for streaming media distribution, APCC2003

RFC2283[14] 吉田 法茂，永渕 幸雄，柳本(2003).

清，渡瀬 順平，高[6] 高木 伸郎，永渕 幸雄，柳本 清，栗林 伸一：ス

木 伸郎：ストリーム配信におけるユーザ視聴品質情トリーミング配信における視聴品質情報管理システ

報を利用した高度ネットワーク制御と新サービスのム（ＬＳＳ−ＳＱＭ），ＮＴＴ Ｒ＆Ｄ Vol.52, No.1,

提案，電子情報通信学会

2003.

信 学 技 報 IN2002-50(2002.7)[7] 詫摩 武永，広野 正巳，松田正之，馬杉 正男：IP[15] 廣瀬 洋一，安部 敦史，渡瀬 順平，栗林 伸一：コ

ネットワーク輻輳時における映像ストリーミング品

ンテンツ配信網における輻輳制御方式の一検討，

質変動検出法の検討，電子情報通信学会 信学技報

2002 年電子情報通信学会総合大会 B-7-73 (2002.9)

NS2002-298 (2003-03)[16] Kentaro OGAWA, Aki KOBAYASHI, Katsunori[8] C. Huang, L. Xu： SRC： Stable Rate Control for

YAMAOKA and Yoshinori SAKAI：Distributed QoSStreaming Media, GLOBECOM2003.

control based on fairness of quality for video streaming,[9] Pai-Hsiang HSIAO, H.T.Kung and Koan-Sin TAN ：IEICE Trans., Commu., Vol.E87-B, No.12, pp.3766-Streaming video over TCP with receiver-based delay

3773 (2004).

control, IEICE Trans., Commun., Vol.E86-B ， No.2,[17] RFC2326 (Real time streaming protocol)

pp.572-584.
[10] 尾上 裕子，荻野 浩明，渥美 幸雄，高橋 修，駒木 寛隆，串田 高幸，山内 長承：マルチメディアス
トリーミング配信サーバにおけるネットワーク情報活用型レート制御方式，情報処理学会論文誌 Vol.44，
No.3，pp.625-636 (2003.3)−17−