IP - Internet Research Lab.

修士論文
2005 年度 (平成 17 年)
パケットフロー観測手法を用いた
受信者駆動型階層化マルチキャストストリーミングの研究
慶応義塾大学院政策・メディア研究科
堀場勝広
修士論文要旨
2005 年度 (平成 17 年度)
パケットフロー観測手法を用いた
受信者駆動型階層化マルチキャストストリーミングの研究
本研究では，輻輳検知にパケットフロー観測手法を用いてレート制御を行う受信者駆動
型階層化マルチキャスト (RLM) を提案し，大規模同報型ストリーミング配信機構を実現
した．
インターネット上の同報型ストリーミング配信の大規模化・高品質化と共に，多様化な
受信環境に対応したストリーミング配信が要求されている．本研究ではストリーミングの
要素を「送信者」
・
「中継網」
・
「受信者」に大別し，各要素の要求に関連するストリーミン
グ技術を整理した．要求事項にストリーミング技術の分析から，送信者と中継網の要求で
ある資源の効率的な活用と，受信者の要求である多様な受信環境への対応と再生品質の保
証の両立が困難なことを示した．
再生品質の保証と，受信者要求に対するスケーラビリティを向上させる技術として，
LM(階層化マルチキャスト) に着目した．関連研究として，既存 LM の研究成果を輻輳検
知とレート制御の主体から RLM(受信者駆動型)・SLM(送信者駆動型)・NLM(ネットワー
ク支援型) に分類し，
「輻輳検知精度」
・
「輻輳収束時間」
・
「規模性」の視点から比較し，規
模性に優れた RLM を選択した．
RLM では輻輳検知とレート制御を受信者が主体となって行う．RLM の既存研究である
Join Experiment 方式では，パケットロスを指標とした輻輳検知を行うため，Leave Delay
と Estimate Delay が問題点とされてきた．本研究では Estimate Delay の短縮を目標とし
て，受信者単体で取得可能なネットワーク状況を示すデータの分析と輻輳メカニズムの
モデル化を行った．モデル化の正当性と実動作確認のための予備実験を行い，パケットフ
ロー観測手法によるジッタ・伝送遅延時間・パケットロスを用いた RLM の輻輳検知手法
を提案した．
パケット観測手法による RLM ストリーミングシステムのプロトタイプとして，Layered
DVTS を設計・実装した．本手法によっての Join Experiment 方式と比較して約 130 ミリ
秒の Estimate Time を短縮し，受信者環境に適応した同報型ストリーミング配信技術の
基礎を構築した．
キーワード
1．受信者駆動型階層化マルチキャスト，2. IP マルチキャスト
3. ストリーミング，4．パケットフロー観測，5．輻輳制御
慶應義塾大学大学院政策・メディア研究科
堀場勝広
Abstract of Master’s Thesis
Academic Year 2005
Research of Receiver-driven Layered Multicast Streaming
using Packet Flow Monitoring Method
In this research, Receiver driven Layered Multicast(RLM) which controls stream rate
by monitoring packet flow for congestion detection is designed and large scale multicast
streaming mechanism is implemented as layered DVTS.
Scalability and quality of broadcast streaming in the Internet is becoming higher and
users diversify demand gave birth to variety of streaming applications. Streaming technology is defined by deviding streaming into 3 dedicated context: “Sender”, “Relay Nodes”,
and “Receiver”. By analyzing each context used within the streaming technology, 2 technical difficulties are being isssued.
1. optimized resource managemenet of sender and relay node request. 2. difficulty in
consistency of quality assurance of stream playback and adaptation of receiver’s demands
based upon various receiver environement.
To solve above 2 difficulties, this research focused on the layered multicast. Comparing
with related mechanism such as: “RLM (Receiver driven Layered Multicast)“, “Sender
driven Layered Multicast (SLM)“, and “NLM (Network driven Layered Multicast)“, this
research fucuses on the RLM mechanism by evaluation of each mechanism by “congestion
detection accuracy”, “congestion decerasing period”, and “scalability”.
RLM prioritizes the congestion detection and rate control by the receiver application.
In the past RLM researches, RLM uses the congestion detection and rate control basis of
“Joint Experiment” by utlizing packetlosses, which will affect “leave delay” and “estimate
delay”. Solution model focuses on decreasing the Estimate Delay receiver driven network
monitoring data analysis and conngestion mechanism modeling. To sustain and confirm its
real operation of the model by exploratory experiment. We designed new RLM congestion
detection model using jitter, transmisson delay and packet losses by monitoring packet
flow.
Layered DVTS is designed and implemented for evaluation of RLM streaming. Layered
DVTS showed decrease around 130msec in estimate time compared to the past researches
using Join Experiment scheme in RLM. Layered DVTS also realized the broadcast streaming technology using the adaptable to receiver environment.
Keywords :
1．Receiver-driven Layered Multicast，2. IP Multicast
3．STREAMING, 4．Packet Flow Monitoring，5．Congestion Control
Keio University , Graduate School of Media and Governance
Katsuhiro HORIBA
目次
第1章
1.1
1.2
1.3
1.4
1.5
1.6
1.7
序論
同報型ストリーミング配信の大規模化と高品質化
IP マルチキャストの必要性 . . . . . . . . . . . .
受信ノードの多様化と IP マルチキャスト . . . . .
通信の信頼性と IP マルチキャスト . . . . . . . .
本研究の目的と意義 . . . . . . . . . . . . . . . .
本論文の構成 . . . . . . . . . . . . . . . . . . . .
本章のまとめ . . . . . . . . . . . . . . . . . . . .
第2章
2.1
2.2
2.3
2.4
2.5
2.6
2.7
本研究の関連技術
ストリーミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ストリーミングと IP ネットワーク . . . . . . . . . . . . . . . . . .
IP マルチキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP マルチキャスト経路制御モデル . . . . . . . . . . . . . . . . . . .
大規模同報型ストリーミング配信に対する IP マルチキャストの効果
ストリーミングのメディア再生品質保証 . . . . . . . . . . . . . . .
LM(Layered Multicast) . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.1 デジタル映像情報の階層符号化方式 . . . . . . . . . . . . . .
2.7.2 階層符号化データの配信 . . . . . . . . . . . . . . . . . . . .
本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8
第3章
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
本研究の関連研究
Join Experiment 方式 . . . . . . . . .
TCP Friendly 方式 . . . . . . . . . .
QoS 方式 . . . . . . . . . . . . . . . .
FEC 方式 . . . . . . . . . . . . . . .
各方式の比較 . . . . . . . . . . . . .
既存 RLM 研究の問題点 . . . . . . .
3.6.1 Estimate Delay に関する議論
3.6.2 Leave Delay に関する議論 . .
FEC 方式の問題点 . . . . . . . . . .
各手法の動作実績 . . . . . . . . . . .
本章のまとめ . . . . . . . . . . . . .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
4
5
5
5
6
.
.
.
.
.
.
.
.
.
.
7
7
8
9
11
12
12
14
14
15
17
.
.
.
.
.
.
.
.
.
.
.
18
18
19
20
20
21
22
23
23
24
24
24
第4章
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
ネットワーク帯域予測
受信者のみで収集可能なネットワーク情報 .
輻輳発生の原因 . . . . . . . . . . . . . . . .
パケットペア理論 . . . . . . . . . . . . . . .
輻輳メカニズムのモデル化 . . . . . . . . . .
パケットフロー観測手法とパケットロス予測
予備実験概要 . . . . . . . . . . . . . . . . .
ジッタとパケットロスの相関 . . . . . . . .
伝送遅延時間とパケットロスの相関 . . . . .
考察 . . . . . . . . . . . . . . . . . . . . . .
本章のまとめ . . . . . . . . . . . . . . . . .
第5章
5.1
5.2
5.3
パケットフロー観測を用いた RLM の提案と DVTS への応用
問題点の整理 . . . . . . . . . . . . . . . . . . . . . . . . . . .
パケット観測を用いた RLM の提案 . . . . . . . . . . . . . . .
本研究における DVTS の位置づけ . . . . . . . . . . . . . . . .
5.3.1 DVTS . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Digital Video フォーマット . . . . . . . . . . . . . . .
Layered DVTS の設計概要 . . . . . . . . . . . . . . . . . . . .
階層化されたデータの分割送信 . . . . . . . . . . . . . . . . .
受信ノード上での輻輳検知とレート制御 . . . . . . . . . . . .
5.6.1 利用可能帯域幅の算出 . . . . . . . . . . . . . . . . . .
5.6.2 パケットロス発生につながるジッタ閾値の設定 . . . .
5.6.3 パケットフロー観測に基づく輻輳予測とレート制御 . .
本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4
5.5
5.6
5.7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
第 6 章 Layered DVTS の実装
6.1 ldvsend の実装 . . . . . . . . . . . . . . . . . . . .
6.1.1 DV データ階層化の実装 . . . . . . . . . . .
6.1.2 音声階層データ定間隔送信の実装 . . . . . .
6.2 ldvrecv の実装 . . . . . . . . . . . . . . . . . . . . .
6.2.1 階層化 DV データ再構成の実装 . . . . . . .
6.2.2 伝送遅延時間算出の実装 . . . . . . . . . . .
6.2.3 ジッタ値計測の実装 . . . . . . . . . . . . .
6.2.4 パケットフロー観測手法を用いたレート制御
第 7 章評価と考察
7.1 定性評価 . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 ストリーミングアプリケーションの機能評価
7.1.2 RLM おける輻輳検知・制御機能の評価 . . .
7.2 Join Experiment 方式との Estimate Delay 比較 . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
28
31
32
34
34
37
38
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
41
41
41
43
43
44
46
46
46
48
.
.
.
.
.
.
.
.
49
49
49
50
51
52
53
54
55
.
.
.
.
56
56
56
57
58
第 8 章結論
60
第 9 章今後の課題
62
謝辞
63
参考文献
66
図目次
1.1
1.2
ストリーミング配信の要素 . . . . . . . . . . . . . . . . . . . . . . . . . . .
受信ノードが持つネットワーク帯域と計算機資源の多様性 . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
ダウンロード方式 . . . . . . . . . . . . . . . . . . . . . .
ストリーミング方式 . . . . . . . . . . . . . . . . . . . .
ジッタがメディア再生品質に及ぼす悪影響 . . . . . . . .
ユニキャストと IP マルチキャストの違い . . . . . . . . .
IP マルチキャストの概要 . . . . . . . . . . . . . . . . . .
デジタル映像情報の階層符号化 . . . . . . . . . . . . . .
通常の IP マルチキャストを用いたストリーミングモデル
LM を用いたストリーミング . . . . . . . . . . . . . . . .
3.1
3.2
Join Experiment 方式を利用した場合の参加階層遷移 . . . . . . . . . . . . 19
FEC 方式 RLM の階層符号化 . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
パケットロス発生メカニズム . . . . . . . . . . . . . . . . . . . . . .
パケットペア理論の概要図 . . . . . . . . . . . . . . . . . . . . . . . .
パケットフローの観察 . . . . . . . . . . . . . . . . . . . . . . . . . .
実験トポロジ図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
伝送遅延 10 ミリ秒で 100Mbps から 20Mbps にシェーピングした場合
伝送遅延 30 ミリ秒で 100Mbps から 20Mbps にシェーピングした場合
伝送遅延 60 ミリ秒で 100Mbps から 20Mbps にシェーピングした場合
伝送遅延 10 ミリ秒で 100Mbps から 25Mbps にシェーピングした場合
定常時 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
輻輳発生時 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
輻輳によるパケットロス発生時 . . . . . . . . . . . . . . . . . . . . .
輻輳収束時 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
伝送遅延 60 ミリ秒で 100Mbps から 20Mbps にシェーピングした場合
伝送遅延 60 ミリ秒で 100Mbps から 24Mbps にシェーピングした場合
伝送遅延 60 ミリ秒で 100Mbps から 27Mbps にシェーピングした場合
伝送遅延 10 ミリ秒で 100Mbps から 20Mbps にシェーピングした場合
5.1
5.2
従来手法と提案手法の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
DV フォーマット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
7
8
9
10
11
15
16
17
27
27
32
33
35
35
35
35
35
35
36
36
36
36
37
37
5.3
5.4
5.5
5.6
設計概要 . . . . . . . . . . . . . . . . . . . . .
IEEE1394 からのデータ入力に従った送信方式
バッファリングによるバースト転送抑制方式 .
レート制御の遷移概要 . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
45
45
47
6.1
6.2
6.3
6.4
送信ノード側実装概要図 .
DV データの階層化 . . . .
受信ノード側実装概要図 .
DV フレームの再構成手法
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
51
53
54
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
表目次
2.1
2.2
2.3
2.4
Multicast Group Address . . . . . . . . . . . . . . . . . . . . . . . . . .
IP マルチキャストによる効果と追加資源要求 . . . . . . . . . . . . . .
ユニキャストと IP マルチキャストに適したネットワーク状況検知手法
再生品質保証方式と効能 . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
10
12
13
14
3.1
RLM，SLM，NLM の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1
4.2
利用機材 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ネットワークパターン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1
7.2
7.3
複数の受信ノードに対するストリーミング配信機能と規模性の比較 . . . . 57
RLM における輻輳検知とレート制御機能の比較 . . . . . . . . . . . . . . . 57
Estimate Delay の低減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
第1章
序論
本章ではインターネット上で展開されている大規模同報型ストリーミング配信と IP マ
ルチキャストの現状を分析し，本研究の目的と意義について述べる．
1.1
同報型ストリーミング配信の大規模化と高品質化
インターネットを基盤とした同報型ストリーミング配信サービスの大規模化，配信され
るメディアの高品質化が進んでいる．著名なアーティストによるインターネットライブの
ストリーミング配信では数万単位を超える視聴者数を記録した．また，メディア品質の点
では，非圧縮ハイビジョン映像の実時間転送が実現された．インターネットが高品質な映
像・音声コンテンツの流通基盤としての役割を果たし始めている．
この様な背景の中で，本研究ではストリーミング技術において大規模化と高品質化に必
要となる 3 つの資源に着目した．
• ネットワーク資源
単位時間あたりのデータ転送能力 (ネットワーク帯域，伝送遅延)
• 計算機資源
単位時間あたりのデータ処理能力 (メディアデータの符号化・復号化，パケット送
信・受信・転送)
• 再生資源
デジタルメディアデータの出力能力 (再生解像度・色階調)
ネットワーク資源では 10GigabitEthernet や WDM，ネットワークプロセッサなどの登
場によって，インターネットバックボーンが広帯域化された．アクセス網は CATV，xDSL，
FTTH などのインターネット接続サービスの普及によって，10Mbps から 100Mbps 程度
の帯域を提供するとともに常時接続サービスとして普及している．また，計算機資源と再
生資源では，プロセッサの高速化に伴うメディアデータの処理速度，メディア出力機器の
高性能化に伴う出力性能が向上し，視聴可能なメディアデータが高品質化した．
これら技術の普及は同報型ストリーミング配信の大規模化につながると同時に，受信
ノード数が増加し受信環境の多様化が進んだ．各受信ノードが要求するストリーミング基
盤技術の品質が受信ノードの持つ計算機資源，再生資源によって異なる．送信ノードで予
め準備すべきメディア品質種類が，受信環境の多様化によってストリーミングに必要とな
1
1.2. IP マルチキャストの必要性
る資源の組み合わせが急増する．そのため，受信ノード数の増加に従って多様な受信環境
への対応が困難になる．
本研究では，同報型ストリーミング配信の大規模化と高品質化に対する要求に基づい
てストリーミング配信における要素を「送信者」，
「中継網」，
「受信者」に大別しする．図
1.1 に各要素を示し，以下にその要求事項まとめる．送信者と中継網のネットワーク資源
をまとめてバックボーンと呼び，受信者のネットワーク資源をアクセス網と呼ぶ．また，
受信者と中継網の接続点をアクセス網ゲートウェイと呼ぶ．また，本研究ではメディアの
再生品質を受信ノード上で再生されるメディアが送信者が意図した品質であることし，そ
れを実現する要素をストリーミング配信の信頼性と定義する．
• 送信者
送信ノードの計算機資源とネットワーク資源の効率利用
• 中継網
中継ノードの計算機資源とネットワーク資源の効率利用
• 受信者
各受信ノードの計算機資源・ネットワーク資源・再生資源に適応したメディア品質
のストリーミング
受信するメディアデータの再生品質
送信者と中継網は同報型ストリーミング配信の大規模化と高品質化に対してストリー
ミング資源の効率利用を要求するが，受信者の要求する多様な環境への対応と相反する．
現状の同報型ストリーミング配信サービスでは送信者と中継網が同一事業者である場合
が多く，受信者環境を限定することで大規模化と高品質化を実現してきた．しかし，同報
型ストリーミング配信の普及とともに大規模化・高品質化だけでなく多様な受信環境への
対応したメディア品質による配信や，再生品質の信頼性が必要となってきた．
1.2
IP マルチキャストの必要性
現状の同報型ストリーミング配信の多くは，ユニキャストを用いた受信ノード群へのデー
タ配信によって成り立っている．ユニキャストでは送信者，中継網の持つ資源の使用量が受
信ノードの数に応じて増加する．そのため，送信ノードと全ての受信ノード間の通信をユ
ニキャストで実現した場合，ストリーミング配信において高い規模性の確保，高品質メディ
アデータの品質保証が困難である．従って，送信者では，送信端末の多重化や，送信ネット
ワークの増強が必要となり，中継網では，輻輳が発生しやすい AS(AutonomousSystem) 間
のリンク，アクセス網へのリンクなど，ボトルネックリンクの帯域増強や CDN(Contents
Delivery Network) の構築が必要となる．しかし，受信者数の増加とメディア品質の高品
質化を同時に満たすボトルネックリンクの増強は困難である．また，CDN では視聴可能
な受信者を接続されるネットワークによって限定し，受信者数を予め予測した上で構築さ
れるが，そのために必要な時間や AS 間での接続調整に多大なコストを要する．
2
第 1 章序論
$& % "'! #
( )'!*#
"! #
'D&,H<>FEIG - ! # &$ % D8,H<>EGI*- !*# ( 'D&8,H5<FEG*- !*#
+,.-0*/ 21
; 3 -54:<C>=:@6:?B9 A 3 -7548&6:9
図 1.1: ストリーミング配信の要素
同報型ストリーミング配信は，同一データを多数の受信ノード群に配送するサービスモ
デルである．このサービスモデルに対して，規模性を確保できる技術に IP マルチキャス
トがある．IP マルチキャストを用いることで，送信者，中継網が必要とする資源が受信
ノード数に依存しなくなる．そのため，これまでの大規模同報型ストリーミング配信に対
して，局地的な IP マルチキャストの利用がされてきた．
しかし，IP マルチキャストはスケーラビリティや運用ノウハウの少なさなど，経路制
御プロトコルの技術的課題や ISP(Internet Service Provider) のサービス運用課題によりイ
ンターネット全体規模での運用では普及していない．そのため，広域サービスとして IP
マルチキャストを提供する場合，AS 間やアクセス網へのゲートウェイも含めたインター
ネット網全域での安定運用が必要となる．
ユニキャストでは同報型ストリーミング配信の大規模化と高品質化を満たす基盤構築に
対する要求が大きい．IP マルチキャストを用いることで基盤構築に対する要求は低減で
きるが，広域ネットワークでの運用は困難である．そのため，送信者と中継網の視点から
資源の利用効率と安定運用のトレードオフが発生している．
3
1.3. 受信ノードの多様化と IP マルチキャスト
1.3
受信ノードの多様化と IP マルチキャスト
1.1 節で述べた受信ノードが持つネットワーク帯域・計算機資源など，ストリーミング
基盤技術の品質向上と同時に，受信ノードが持つ資源の多様化が進んでいる．大規模同報
型ストリーミング配信において，受信者は多数存在し，各受信ノードが要求するストリー
ミング基盤技術の品質は受信ノードの持つ端末資源，再生資源によって異なる．
図 1.2 に受信ノードが持つネットワーク帯域，計算機資源の多様性と，各受信ノードに
おいて最適なメディア品質が異なることを示す．図 1.2 の wireless 802.11a のネットワー
ク接続性を持ち，画面解像度が XGA のラップトップコンピュータと，128kbps のネット
ワーク接続性を持ち，画面解像度が QVGA の PDA では受信する可能なメディアデータ
量，再生可能なメディア品質が異なる．
FTTH (100Mbps)
Internet
Contents Distributer
Wireless 802.11a (54Mbps)
ADSL (Up:1.5Mbps / Down:24Mbps)
PHS (128kbps)
Cellar Phone (38.4kbps)
User Request Query
Contents Data Distribution
図 1.2: 受信ノードが持つネットワーク帯域と計算機資源の多様性
ユニキャストを用いた場合，通信セッション数と受信ノード数が一致するため受信環境
の多様性に個別対応できる．IP マルチキャストは同一データを多数の受信ノード群に配
送するのに適した通信方式であるが，各受信ノードの状況に個別対応することは困難であ
る．そのため，送信者，中継網の要求を満たすためには IP マルチキャストが最も効率の
良い解決策だが，受信者が要求する多様な受信環境に対応したストリーミング配信を IP
マルチキャストで実現するのは困難である．
4
第 1 章序論
1.4
通信の信頼性と IP マルチキャスト
インターネットを基盤としたストリーミング配信では多くの場合ベストエフォート型
であるため，通信の信頼性を中継網が保証しない．この問題に対して，現状のストリー
ミングサービスでは送信者によって複数ビットレートのメディアが用意され，受信者は受
信ノードの計算機環境・ネットワーク環境に適していると思われるビットレートを受信者
が選択する．しかし，ネットワーク環境は常時変化しているため，輻輳が起こった際は受
信ビットレートを低減させなければ視聴しているメディアデータの再生品質が低下する．
この問題に関して，ユニキャストでは送信ノードと受信ノード間で受信データ状況を伝あ
うことによって，現在のネットワーク帯域に対して再生品質の良いビットレートの選択を
実現している．しかし，IP マルチキャストでは全ての受信ノードからのネットワーク状
況報告を参照し，全ての受信ノードを満足させるメディア品質のデータ配信を実現できな
い．全受信ノードからのネットワーク状況報告を 1 つの送信ノードが受信した場合，送信
ノードに対して過上な負荷が発生しサービスダウンに繋がる．そのため，受信者の要求で
ある再生品質の信頼性確保と送信者・中継網の要求である効率のよい資源活用の両立は困
難である．
1.5
本研究の目的と意義
同報型ストリーミング配信の大規模・高品質化と IP マルチキャストに関して，送信者，
中継網の要求はストリーミング基盤となる資源を効率良く利用した大規模なサービス構
築であるが，受信者の要求は環境に適応したメディア品質への対応と再生品質の確保で
ある．
本研究では，送信者，中継網，受信者の相反する要求を同時に満たし，多様な受信環境
に適応した大規模同報型ストリーミング配信環境を実現することを目的とする．具体的に
は，階層化マルチキャスト (LM:Layered Multicast) の持つ輻輳検知，レート制御の問題
点を解決し，通常 IP マルチキャストでは実現困難な受信環境に応じたデータ配送機能と，
配送データの信頼性を実現する．
1.6
本論文の構成
本論文は 9 章で構成される．第 2 章では本研究の関連技術としてストリーミング，IP
マルチキャスト，LM の概要を述べる．第 3 章で，LM の関連研究として，RLM，SLM，
NLM について述べ，それぞれの比較から既存の LM の輻輳検知・制御が抱える問題点に
ついて分析し，大規模同報型ストリーミング配信おける LM の輻輳検知・制御の手法につ
いて検討する．第 4 章では，受信ノード単体で機能する輻輳検知・制御手法について分析
し，ジッタや遅延とパケットロスの関係について述べる．第 5 章では，本研究のアプロー
チとして第 2 章で述べた問題の解決方法を提案し，DVTS[1] において LM の活用を活用し
た Layered Multicast の設計について述べる．第 6 章では Layered DVTS の実装について
5
1.7. 本章のまとめ
述べる．第 7 章では，本研究の提案手法と実装に関する評価を行う．第 8 章では，本論文
の結論として本研究のまとめと今後の課題について述べる．
1.7
本章のまとめ
本章では，大規模同報型ストリーミング配信を，
「送信者」，
「中継網」，
「受信者」に大別
し，それぞれの要求を整理した．そして，送信者，中継網の要求には IP マルチキャスト
が適していることを示した．また，受信ノードの多様性を示し，受信者の要求と送信者，
中継網の要求を満たす IP マルチキャストが相反する関係であることを示し，本研究が解
決する問題点を明らかにした．
次章では，本研究の要素技術について述べ，大規模同報型ストリーミング配信を多様な
受信環境に対応させる手法を議論する．
6
第2章
本研究の関連技術
本章では本研究に関連する技術として，ストリーミング，IP マルチキャストの技術概
要について整理し，本研究で解決する技術的問題点を明らかにする．問題解決のアプロー
チとして既存研究である階層化マルチキャスト (LM:Layered Multicast) に着目し，スト
リーミングを LM 上で実現するための技術的な課題を明らかにする．
2.1
ストリーミング
IP ネットワーク上での映像・音声などのメディア配信技術はダウンロード方式とスト
リーミング方式に大別される．図 2.1 にダウンロード方式を，図 2.2 にストリーミング方
式を示す．
Sender
Receiver
Decoder
Transmission Start
1
2
3
4
Play Start
1
2
3
4
図 2.1: ダウンロード方式
ダウンロード方式は，メディアデータ全体を送信ノードから受信ノードへ転送した後に
再生するメディア配信方式である．一方ストリーミングは，送信ノードから配信されるメ
ディアデータを受信ノード上で逐次再生するメディア配信方式である．ストリーミング方
7
2.2. ストリーミングと IP ネットワーク
Sender
Receiver
Decoder
Transmission Start
1
2
3
4
Play Start
1
2
3
Transmission Complete
4
図 2.2: ストリーミング方式
式はダウンロード方式に対して，ネットワーク帯域に対して大容量なメディアデータを少
ない待ち時間で再生できる点が特徴である．また，メディアの開始と終了が明確でないラ
イブ配信を実現できる．
2.2
ストリーミングと IP ネットワーク
IP ネットワークはベストエフォート型のネットワークである．そのため，送信ノードか
ら受信ノードへのパケット到達性，パケット到達時間，パス上のネットワーク帯域，デー
タの完全性をネットワークが保証しない．以下にストリーミングにおける受信ノード上で
のメディア再生品質維持に必要な要素と，各要素が満たされなくなる原因を示す．
• データの完全性
送信ノードが送信したデータを受信ノードがパケットロス無く受信すること
原因: ネットワーク帯域不足によるパケットロス
• バッファ超過の回避
受信ノードが持つ受信パケットバッファ長を超える過剰なデータ送信の回避
原因: 送信ノードのバースト転送
• バッファ枯渇の回避
受信ノード上のメディア再生速度が，パケットの受信速度を超過し，受信パケット
バッファを枯渇させることの回避
原因: パケット到達時間の遅延，ジッタ
8
第 2 章本研究の関連技術
図 2.3 にストリーミングにおいて，ジッタがメディア再生品質に悪影響を及ぼすデータ
転送の例を示す．ジッタが無い状態でパケットが到達している時間 A の部分では，メディ
ア再生品質に影響は無い．しかし，時間 B の部分では 1 つのパケット到達時間の遅延 (パ
ケット到達間隔のジッタ) が発生し，メディア再生速度に対して受信パケットバッファが
一時的に枯渇している．この結果，メディア再生品質が低下する．
%$ &
'
!
" #
(
図 2.3: ジッタがメディア再生品質に及ぼす悪影響
2.3
IP マルチキャスト
IP マルチキャストは同一のデータを複数の受信ノードに対して，中継ネットワーク帯
域および送信ノードの負荷を最小限に配信することを目的として考案された技術である．
図 2.4，図 2.5 に IP マルチキャストの動作概要を示す．
同一の情報を複数の受信ノードに送信する場合，ユニキャストでは送信ノードが送信す
るパケットの宛先情報に受信ノードの IP Address を記述する．ユニキャストでは，送信
ノードは受信ノードの数に応じてデータを複製送信する必要があるため，ネットワーク帯
域への負荷，送信ノードへの計算負荷が受信ノードの数に応じて増加する．一方 IP マル
チキャストでは，送信ノードは送信されるパケットの宛先情報に Group Address と呼ば
れる特殊な IP Address を記述し，単一の宛先へ送信する．
表 2.1 に Group Address で利用される IP Address の範囲を示す．パケットを中継する
ルータは，パケットの宛先 IP Address が Group Address であることを確認することで，
IP マルチキャストとして処理する．
IP マルチキャストでは，送信ノードは受信ノードの数に依存せず単一のデータフローが
発生する．そのため，送信ノードと同一ネットワーク上のマルチキャストルータ間のネッ
9
2.3. IP マルチキャスト
" #$%'&)(
" #$%'&+*
! 図 2.4: ユニキャストと IP マルチキャストの違い
IP version
IPv4
IPv6
表 2.1: Multicast Group Address
IP Address Range
224.0.0.0 - 239.255.255.255
上位 8 ビットが FF(16 進数) となる IPv6 アドレス
トワーク帯域への負荷，送信ノードへの計算負荷が受信ノードに依存せず一定である．受
信ノードは Group Address に対して，IPv4 の場合は IGMP(Internet Group Management
Protocol)，IPv6 の場合は MLD(Multicast Listener Discovery) を用いて，Join/Leave 要求
を発行する．受信ノードから Join 要求を受け取った受信ノードと同一ネットワーク上に
位置するマルチキャストルータは，受信ノードのクエリーを集約し，自ネットワークから
対象となる Group Address へ参加要求をマルチキャスト経路制御機構を用いて上位マルチ
キャストルータへ通知する．受信ノードからの受信要求クエリーを代表して受信し，集約
することからネットワーク内の Join/Leave 要求を管理するマルチキャストルータをクエ
リアと呼ぶ．マルチキャスト経路制御手法は様々なプロトコルが存在するが，基本的に参
加要求に基づいて送信ノードを頂点とするディストリビューションツリーが構成される．
各マルチキャストルータはディストリビューションツリーに基き，転送すべきネットワー
クインターフェースに対して，上位マルチキャストルータより受信したデータのコピーを
10
第 2 章本研究の関連技術
./&(0 23546('74
8:9 ;=<=>
?&1$ 9 @BADC0 E 9 41$ 0 2GF
!"
!"
J5479 K&1$ LM*N-O
# $ &1'
)*+-,
%
PHQHRHS
J5479 K&1$ LUTN-O
# $ &1'
)*+-,
%
PHQHRHS
VWYXZ
#%$ &(')*+-,
./&10 23546('74
8:9
#%$ &(')*+-,
./&10 23546('74
8:9
V[X\
!"
!"
./&(0 235461'G4
8:9 ;=<H>
?&1$ 9 @IAIC0 E 9 41$ 0 2GF
図 2.5: IP マルチキャストの概要
転送する．データフローを受信したマルチキャストルータは，対象となる Group Address
の MAC(Media Access Control) Address をブロードキャストと結びつけ送信する．その
際，IGMP/MLD Snooping が有効なレイヤ 2 スイッチでは，Join 要求を受信したスイッ
チのポートのみパケットの転送を行う．
2.4
IP マルチキャスト経路制御モデル
IP マルチキャストの経路制御モデルは，ASM(Any Source Multicast) と SSM(Source
Specific Multicast) に大別される．ASM では，受信ノードは参加要求を示す Group Address
のみを指定する．そのため，受信ノードからは特定 Group Address を宛先として送信し
ているノードを判別することはできないが，複数の送信ノードからのパケットを受信でき
る．ASM ではマルチキャストルータの経路表に対して，該当する Group Address を (*,G)
と表記する．
「G」は Group Address を示す．SSM では，受信ノードは参加要求を送信する
Group Address と同時に，送信ノードの IP Address を指定する．そのため，指定された送
信ノード以外はデータ配送を行わない．また，Group Address と送信ノードの IP Address
のペアを Channel と表現する．そのため，マルチキャストルータの経路表に対して，該当
する Channel を (S,G) と表記する．
「S」は送信ノードの IP Address を示す．
11
2.5. 大規模同報型ストリーミング配信に対する IP マルチキャストの効果
IP マルチキャストの経路制御では，送信ノードから受信ノードに至るマルチキャスト経
路表を動的に生成する．そのため，ASM では受信ノードからの参加要求に対して，送信
ノードを調査する必要がある．また，複数の AS 間など異なる運用ポリシを持つ組織間で
ASM を用いた場合，MSDP(Multicast Source Discovery Protocol) などを用いて送信ノー
ドの IP Address と Group Address の関係を解決する必要がある．SSM では，受信ノード
からの参加要求に送信ノードが記述されているため，ASM と比較してマルチキャスト経
路表の作成が容易である．
2.5
大規模同報型ストリーミング配信に対する IP マルチキャ
ストの効果
表 2.2 に大規模同報型ストリーミング配信に対して，IP マルチキャストを導入すること
で得られる効果，導入によって必要となる追加資源要求をまとめる．
要素
送信者
中継網
受信者
表 2.2: IP マルチキャストによる効果と追加資源要求
追加資源要求
直接的な効果
間接的な効果
なし
マルチキャスト
ルーティング
なし
消費資源の低減・一定化
消費ネットワーク
資源の低減
なし
なし
なし
受信可能性・品質の向上
IP マルチキャストは送信者に対して受信ノード数に非依存な一定資源消費量を保証す
る．また，中継網に対して中継ノードの計算機資源に IP マルチキャストルーティング処
理を追加要求するが，消費するネットワーク帯域の低減による効率の良い同報通信が可能
となる．そのため，同報型ストリーミング配信の大規模化と高品質化に対して有効な技術
である．受信者に対しては，ユニキャストとほぼ同等の資源消費量であるが，送信者，中
継網の資源消費量低下によって資源枯渇によるサービス停止の可能性が低い．また，送信
者と受信者の持つ資源を効率よく利用することで，間接的に同一資源上で実現可能なスト
リーミングの大規模化と高品質化が実現する．
2.6
ストリーミングのメディア再生品質保証
2.2 節で述べたストリーミングにおけるメディア再生品質を低下させる原因が発生した
場合，再生品質を維持するためには送信ノードと受信ノード間のパス上におけるネット
ワーク状況を検知し，パス上を通過するビットレートを低下させる必要がある．一般的に
ストリーミングアプリケーションはトランスポート層通信プロトコルに UDP[2] と RTP[3]
を用いて実装される．また，RTP 通信上でネットワーク状況を補助的に通知するプロト
コルに RTCP がある．
12
第 2 章本研究の関連技術
しかし，パス上のネットワーク状況の検知は，ユニキャストと IP マルチキャストのそ
れぞれに対して適している手法が異なる．表 2.3 にメディア再生品質を低下させる原因の
発生を検知する手法と適している通信方式を示す．
表 2.3: ユニキャストと IP マルチキャストに適したネットワーク状況検知手法
通信方式
受信ノード・中継ノード間の連携
送信ノード・受信ノード間の連携
IP マルチキャスト
ユニキャスト
○
○
○
×
表 2.4 に，各方式，及び通信プロトコルを利用することで得られる規模性，ネットワー
ク状況把握の正確性，ネットワーク状況把握とレート制御の迅速性，インターネット上で
の動作に対する現実性を示す．
受信ノード・中間ノード間の連携の例として ECN(Explicit Congestion Notification)[4]
が挙げられる．送信ノード・受信ノード間のパス上におけるパケットロスの多くは，パス
上のボトルネックとなる中継ノードのネットワークインターフェースキューを超過するパ
ケット入力起因する．ECN では中継ノードがキューの状態を管理し，転送待ちパケット
数が一定のレベルに達した際，転送待ちのパケットの CE(Congestion Experience) ビット
を設定する．受信ノードがパケットの CE ビットを検査することでネットワークの状態を
正確かつ，迅速に把握できる．しかし，パス上の中継ノード全てが ECN に対応している
必要があるため現実的ではない．
送信ノード，受信ノード間の連携の例として，RTP(Real-time Transport Protocol)[3]
と RTCP(RTP Control Protocl) を用いた輻輳検知に基づいたレート制御手法が挙げられ
る．RTP と RTCP を用いることでパケットロス・伝送遅延時間・伝送遅延時間の揺らぎ
等を利用したネットワーク状況の把握を行い，送信ノードでのレート制御を行う輻輳制御
手法である．ユニキャストでは，送信ノードと受信ノードの関係が 1 対 1 であるため，両
者の情報交換が計算機資源の大きな負荷にはならない．そのため，送信ノードと受信ノー
ド間での情報交換に基づく受信ノードからのレート制御要求に対して，送信ノードによる
制御を容易に実現できる．しかし，大規模同報型ストリーミング配信では受信ノード数が
複数となり，送信ノードと受信ノードの関係が 1 対 N になる．そのため，送信ノードと
受信ノード群間のネットワーク情報交換が送信ノードの大きな負荷となる可能性がある．
IP マルチキャストでは，送信ノードと受信ノードの関係が 1 対 N になるが，送信ノード
の負荷は受信ノード数に非依存で一定となる．そのため，ストリーミング配信に対する資
源要求が低減できるが，送信ノードと受信ノード群間のネットワーク情報交換における負
荷はユニキャストと同一である．また，送信ノードと受信ノードが間で現状のネットワー
ク状況検知，送信ノードによるレート制御は，多数存在する受信ノード群に対して個別に
対応できない．
中継網・受信者によるメディア品質保証，通信プロトコルに関係なく中継ノードの情報
に基づくネットワーク状況把握である．そのため，ボトルネックリンクの特定，輻輳状態
13
2.7. LM(LAYERED MULTICAST)
連携要素
中継網・受信者
送信者・受信者
送信者・受信者
表 2.4: 再生品質保証方式と効能
通信プロトコル
規模性正確性
問わない
ユニキャスト
IP マルチキャスト
×
×
○
◎
○
○
迅速性
現実性
○
○
○
×
△
○
の検知が正確かつ迅速であるが，
パス上の全中継ノードにその機能が必要となるため規模性に欠ける．また，現状のイン
ターネットにおける中継ノードに対してパケット転送以外の追加要求をすることは現実的
ではない．送信者・受信者では，中継網に追加機能要求が無いため現実的だが，ユニキャ
ストの場合は送信者の端末資源，ネットワーク資源を過剰利用する可能性がある．また，
IP マルチキャストを用いた場合，ストリーミング配信に関する資源利用量を低減できる
が，受信ノード群からの情報交換に対する負荷により，送信者の端末資源を過剰消費する
可能性がある．
2.7
LM(Layered Multicast)
LM は IP マルチキャストにおける，送信ノードによるストリーミングの送信ビットレー
ト制御ができない問題に対して，受信者によるビットレート制御を可能にする技術であ
る．LM は，配信データを階層符号化し，各階層を個別の Group Address と結びつけて
データ配信を行う技術である．受信ノードは，自ノードが持つ資源に応じて Join 要求を
行う Group Address を動的に変化させ，自ノードが受信可能なデータ品質を選択する．
2.7.1
デジタル映像情報の階層符号化方式
階層符号化は，解像度等を変化させた画像を階層的に複数用意し, 画像の階層数に応じ
て品質を選択できる符号化方式である. 図 2.6 に，デジタル映像情報の階層符号化を示す．
階層符号化では，各階層ごとに符号化を行ない, 下位レイヤを補完する形で上位レイヤが
存在する. 画像は最低限の品質を提供する Base Layer と，それに追加することでより高品
質な画像を提供する Enhanced Layer に分類される．Enhanced Layer 数が Low から High
に増加するに従って，映像品質が徐々に向上する．階層符号化方式を用いることで，単一
データから視聴者の環境に応じたメディア品質の調整が可能となる．
階層符号化のアルゴリズムは解像度だけでなく，フレームレートや色階調など，他の画
像品質をメトリックとすることで実現可能である．解像度をメトリックとして階層符号化
を利用した映像メディアの例として，MPEG2 SNR Scalable/Spatial Scalable Profile[5],
JPEG2000 EBCOT (Embedded Block Coding with OptimizedTruncation)[6, 7] の二つが
挙げられる．また，階層化する際の注意点として，再生品質を維持するために均一性を考
14
第 2 章本研究の関連技術
慮する必要がある．例えばフレームレートでは，再生品質維持のためフレーム間隔を均一
にする必要がある．
Enhanced n
Enhanced 3
Enhanced 2
Enhanced 2
Enhanced 1
Enhanced 1
Base
Base
Base
Low
High
Quality
Enhanced n
Base+Enhanced x n
Enhanced 5
Enhanced 4
Base+Enhanced x 3
Enhanced 3
Enhanced 2
Enhanced 1
Base only
Base
図 2.6: デジタル映像情報の階層符号化
2.7.2
階層符号化データの配信
LM では，階層符号化されたデータの各レイヤを Group Address に結びつけ配信する．
図 2.7 に通常の IP マルチキャストを用いたストリーミングモデルを示し，図 2.8 に LM を
用いたストリーミングモデルを示す．
通常の IP マルチキャストは，単一のデータを単一の Group Address に結びつけ配信す
るため，十分なネットワーク帯域を確保できないリンク上ではパケットロスが発生する．
従って，送信ノードと受信ノード間のパスに一箇所でも十分な帯域が確保されない場合，
受信ノードではメディアの再生品質が低下する．図 2.7 では，送信ノードから無線 LAN 網
へのパス上では，30%のパケットロスが発生するボトルネックリンクを含むが，Ethernet
網へのパス上では十分な帯域が確保されている．そのため，無線 LAN 網に接続している
ノードでは再生品質が保たれない．
15
2.7. LM(LAYERED MULTICAST)
/(!)-* ,
,
(!)-* ,,
().* ,
,
(!)+* ,
,
0(!)-* ,
,
0(!)-* ,
,
!
1 (!)-* ,,
"$# %'& 図 2.7: 通常の IP マルチキャストを用いたストリーミングモデル
LM では，送信ノードと受信ノード間のパス上で利用可能なネットワーク帯域に応じ
て，受信ノードの Join 要求を変化させる．少なくとも Base Layer をパケットロス無く受
信可能な帯域が確保できた場合，受信ノードでは Base Layer のメディア品質で再生品質を
低下させること無く配信メディアを視聴することができる．また，いくつかの Enhanced
Layer を追加することで，送信ノード・受信ノード間のパス上で利用可能なネットワーク
帯域に応じて再生品質を低下させずにメディア品質を向上可能である．図 2.8 では，送信
ノードが一つのメディアデータを階層符号化によって 3 つに分割している．受信ノード群
は送信ノードと自ノード間のネットワーク帯域や，自ノードの端末資源，再生資源に応じ
て，受信する階層数を変化させ，メディア品質を調整することで再生品質を確保してい
る．従って，LM を用いることで受信ノードの持つネットワーク帯域，計算機資源に応じ
たストリーミング配信が可能となる．
しかし，2.6 節で述べた通り，IP マルチキャストのデータ配信モデル上で，送信ノード
と受信ノード間のパス上でネットワーク帯域に関してボトルネックとなるリンクの特定，
利用可能なネットワーク帯域を特定するのは困難である．また，パス上で利用可能なネッ
トワーク帯域は常時変化し続けているため，ストリーミングメディアの品質保証に対し
て，細かな粒度での配信データの帯域調節が必要となる．
そのため，LM を利用する場合は受信ノードが単独で現在利用できるネットワーク帯域
を測定する必要がある．測定された最適なネットワーク帯域に応じて，受信ノードはレイ
16
第 2 章本研究の関連技術
!
(*)+ -) , -) -
) , /.
-) 0! ) , 1
"$# %'& 図 2.8: LM を用いたストリーミングモデル
ヤに結び付けられた Group Address に対して Join 要求，Leave 要求を発行し，自身が受
信するデータの帯域を調節する必要がある．
2.8
本章のまとめ
本章では，本研究の関連技術としてストリーミング，IP マルチキャストの技術的概要
を述べ，IP マルチキャストのメディア配信モデル上でのストリーミングメディア品質の
保障に関する問題点を明らかにした．また，IP マルチキャストを用いたストリーミング
におけるメディア品質保証のレート制御方式として LM を挙げ，技術概要と LM に適した
ネットワーク状況の検知手法について述べた．
次章では，LM の関連研究としてネットワーク状況検知，最適帯域探索手法について述
べ，既存研究の抱える問題点を明らかにする．
17
第3章
本研究の関連研究
本章では，階層符号化マルチキャストの関連研究の概要について述べる．階層符号化マル
チキャストの先行研究は，レート制御を行う主体から受信者駆動型 (RLM: Receiver-driven
Layered Multicast)，送信者駆動型 (SLM: Sender-driven Layered Multicast)，ネットワー
ク支援型 (NLM: Network-supported Layered Multicast) に大別される．
RLM には，Join Experiment 方式，SLM には TCP Friendly 方式，NLM には QoS 方
式が該当する．FEC 方式はいずれにも該当しない信頼性マルチキャスト (RM:Reliable
Multicast) 技術だが，全ての階層符号化マルチキャスト方式に適用可能なエラー定性技術
である．
本章では，Join Experiment 方式，TCP Friendly 方式，QoS 方式の特性について述べ，
どの方式が実ネットワーク上で動作させるのに適しているか方式かを議論する．また，適
している方式が現在抱えている問題点をストリーミングのメディア再生品質，最適帯域調
査手法の観点からまとめる．
3.1
Join Experiment 方式
Join Experiment 方式の RLM は，初めに RLM が発表された際に考案された受信ノー
ド単体での最適帯域調査である．Join Experiment 方式では，受信ノードがパケットロス
による輻輳を検知するまで Join-Timer で設定した時間毎に Join 要求を発行するレイヤ数
を増加させる．図 3.1 に最大 4 つのレイヤを受信可能な LM の場合におけるトレート制御
の様子を示す．
はじめに図中 (A) において，受信ノードは Base Layer である Layer 1 に対して Join 要求
を送信し，Join-Timer をセットする．Join-Timer でセットした時間が経過した後，パケッ
トロスによる輻輳が検知されなかった場合，Join Experiment が成功したとみなす．図中
(B) において，Enhanced Layer である Layer 2 への Join 要求を追加し，新たな Join-Timer
をセットする．
いくつかの Join Experiment が成功した後，図中 (C) の期間でパケットロスによる輻輳
を検知し，同時に現在参加しているレイヤの中で最も高いレイヤの Group Address に対
して Leave を発行し，レイヤを放棄する．輻輳を検知した場合，Join-Timer を輻輳検知
前よりも指数関数的に長く取り，Join/Leave 要求のフラッピングを避ける．しかし，Join
Experiment 方式は単純にパケットロスの発生に対して最上位レイヤの Group Address か
ら Leave をするのみで，現状利用可能な帯域幅や輻輳の粒度については議論されていな
い．また，複数の LM が同一サブネットで受信される場合，先に受信を開始したコンテン
18
第 3 章本研究の関連研究
$#
!%&
!'"
!()
!"
図 3.1: Join Experiment 方式を利用した場合の参加階層遷移
ツが後に受信を開始したメディアデータと比較して多くの帯域を消費するため，公平性が
保てない．
3.2
TCP Friendly 方式
TCP Friendly 方式 LM は，TCP-Friendly[8] を参考にしたレート制御を LM に適用した
ものである．
TCP Friendly は，1997 年に S.Floyd らによって提案された UDP に代表されるコネク
ションレス型通信プロトコルと TCP に代表されるコネクション型通信プロトコルがネッ
トワーク帯域を公平に共有するためのアルゴリズムである．
TCP-Friendly では，p をパケットロス率，s をパケットサイズ，RT T を RTT(Round
Trip Time)，c を 0.9 - 1.5 の間の定数とした場合，式 4.1 によって現状利用可能な帯域幅
T を算出する．
T =
(s × c)
RT T × sqrt(p)
(3.1)
TCP Friendly 方式の LM[9, 10, 11] では，この式を調整することで IP マルチキャスト
上での輻輳検知を行っている．いずれの方式も SLM が用いられ，受信ノードの状況を送
信ノードに伝えることで送信者によるレート制御が行われる．そのため，TCP Friendly
を用いることで，他の TCP 通信と利用帯域の公平性が保たれるだけでなく，他の LM の
利用帯域との公平性が保たれる．
19
3.3. QOS 方式
SLM では受信ノード群から送信ノードへのネットワーク状況通知の集中を避け，輻輳
状態を正確に得るために，サブネット毎に最悪の受信環境を持つノードを代表として選
出する．選出された代表受信ノードの受信状況に応じたレート制御を送信ノードが行う．
しかし，代表となるノードはネットワーク状況に応じて変化するため，送信ノード，受信
ノード群間の情報交換量は減少せず，送信ノードは全ての受信ノードと通信をする必要が
ある．
また，送信ノードが主体となったレート制御のため，送信ノードは輻輳状態に応じてク
ラス分けをした受信ノード群に対してデータ送信をする必要があるため，送信ノードが属
するサブネットのマルチキャストルータと送信ノード間のリンクがボトルネックリンクで
ある場合に輻輳状態が悪化する．
3.3
QoS 方式
QoS(Quality of Service) は特定の通信のための帯域を予約や，一定の通信品質の保証な
どを行う技術である．具体的には中継ノード上で輻輳を検知した場合，ネットワークイン
ターフェースキュー上で特定パケットを優先的に処理する方法や，優先度の低いパケット
を優先的に破棄する方法 (優先破棄機構) などがある．
QoS 方式の階層符号化マルチキャストでは，一般的に優先破棄機構が活用され，Base
Layer から最上位 Enhanced Layer へ，順に高い優先度を設定しする．Base Layer の品質
を保証するために，中継ノードは輻輳時に優先度の低いパケットから破棄する．
NLM のレート制御は中継ノード上のフィルタリングによって実現される．中継ノード
が持つネットワークインターフェースキューが混雑することによって輻輳を検知し，現在
転送している LM の最上位階層から順にフィルタリングを行う．また、一定時間以上輻輳
状態が続く場合は上位のマルチキャストルータに対して対象階層の転送停止を要求する．
3.4
FEC 方式
FEC(Forward Error Correction) は，データの廃棄や誤りを検出した時に，そのデータ
を再送することなく，転送すべきデータに付加した冗長データを用いて、復元する通信方
式である．再送を用いない片方向のデータ転送に対して適用され，Reliable Multicast(信
頼性マルチキャスト) などにも用いられる手法である．
FEC 方式 RLM である LLM[12] では，階層符号化によって得られるメディアデータを
Message と呼び，メッセージから誤り訂正符号を用いて生成するデータ Parity と呼ぶ．
Parity を各階層の FEC として実装することで，各階層のデータ欠損に対する耐性を高め
ている．
図 3.2 に FEC 方式 RLM で用いられる FEC を用いた階層符号化方式を示す．LLM では，
Message 階層一つに対して Parity を一つ用意し，Parity に対しても Group Address を割
りあてることで，レート制御の 1 単位に加える．図中の四角内の番号は，Group Address
の階層レベルを示している．Parity も通常の階層符号化マルチキャストと同様のアルゴリ
20
第 3 章本研究の関連研究
ズムで利用することで，FEC を実現している．また，LLM では Join Experiment 方式を
用いて最適受信可能帯域探索を行っているため RLM に分類されるが，FEC を利用した
LM は NLM にも適用可能である．
/0 '+2143$,5 6
(*)+$,)$-.#"$%&' (*)+$,)$-.#"$%&' *( )+$,)$-.#"$%&' !#"$%&'
図 3.2: FEC 方式 RLM の階層符号化
フレーム間圧縮映像フォーマットように，特定のデータが映像の複号化に重要な役割を
占める場合，FEC によるエラー定性は大きな効果を発揮する．しかし，FEC を用いるこ
とで輻輳状態において完全なデータ復元が実現する保障は無い．
3.5
各方式の比較
これまで述べてきた関連研究概要より，RLM，SLM，NLM の比較を表 3.1 に示す．
表 3.1: RLM，SLM，NLM の比較
レート制御主体帯域予測精度輻輳収束時間
RLM
SLM
NLM
低
中
高
遅
中
速
規模性
高
低
低
RLM では各受信者がネットワーク状態を推定し，受信階層数の増減を決定する．中継
ノードが輻輳に対して，フローや優先度を考慮せずにパケットを drop-tail で破棄するモ
デルを前提とし，中継ノード群が輻輳状態を明示的に受信ノード群に通知しないことを
前提とする．SLM では送信ノード，受信ノード間の情報交換によって RLM と比較する
21
3.6. 既存 RLM 研究の問題点
と高精度な利用可能帯域の推測ができる．また，他のセッションとの公平性を確保でき
る．NLM では輻輳を検出した中継ノードがパケットの優先破棄を行うため，優先度の高
い Base Layer のパケットロスを防止できる．
NLM による輻輳検知は RLM，SLM による輻輳検知と比較して，中継ノード上のネッ
トワークインターフェースキューを観測可能なため，迅速かつ正確である．しかし NLM，
SLM ではパケットロスの発生を起点とした輻輳検知を行うため，メディア再生品質が一
度低下した後に輻輳制御を行うこととなる．
また，NLM，SLM によるレート制御は RLM によるレート制御と比較して，クエリア
による配下のサブネット内ノードの Leave 要求を待つ必要がないため迅速である．そのた
め，従来 RLM は階層符号化マルチキャストには適さないとされてきた [13]．
しかし，NLM，SLM を現状のインターネット上で実現するのは困難である．2.6 節で
述べた通り，現状のインターネット上では全ての中継ノードに対してルーティング，フォ
ワーディング以外の機能を期待することは非現実的である．また，QoS に関しては極少数
の優先されるパケットのみをターゲットした場合は動作するが，輻輳状態かつ，QoS の対
象となるパケットが多様な場合，正しく動作しない [14]．
また，受信ノード群のネットワーク状況を送信ノードに通知する SLM では，受信ノー
ド数に応じて送信ノードの負荷が高くなるため，IP マルチキャストが持つ規模性と相反
する．以上のことから，本研究では RLM に着目し，の既存研究の問題点を整理する．文
献 [13, 15] では，受信者駆動型が階層符号化マルチキャストに対して不向きな理由として，
帯域予測精度，輻輳収束時間の観点から以下の 2 点とまとめている．
• 受信者によるネットワーク状態の推定による遅延 (Estimate Delay)
受信ノードはパケットロスのみからネットワーク状態を推定するため，推定要素を
検知した時点で再生品質が低下している．
• IGMP，MLD における Leave メッセージの処理遅延 (Leave Delay)
クエリア，受信ノード群間での Leave 要求の処理から，実際にデータフローが停止
するまでの遅延時間により，輻輳状態から回復するまでの遅延時間が発生する．
3.6
既存 RLM 研究の問題点
RLM では送信ノードと受信ノード群間のネットワーク状況情報の交換による送信ノー
ド主体のレート制御ができない．受信ノード群が自律的に Join 要求を発行する Group
Address 数を調節することでレートを制御する．そのため，受信ノード群のみで利用可能
な帯域幅を判断する必要がある．また，受信ノード群が Leave 要求を発行した後，実際に
データフローが停止し輻輳が収束する時間と再生品質の関係についても議論する必要が
ある．これらの問題に対して既存研究が抱える問題点を以下にまとめる．
22
第 3 章本研究の関連研究
3.6.1
Estimate Delay に関する議論
パケットロスを受信ノードにおける輻輳検知手法として用いた場合，文献 [13, 15] が示
す通り，輻輳状態の発生と輻輳制御の適用に大きな遅延が発生する．そのため，受信ノー
ド上でのメディア再生品質は大きく低下する．そのため，従来の受信者駆動型のレート制
御では受信ノード上の再生品質低下から収束まで大きな遅延時間が発生する．従って，輻
輳が発生する前に受信ノード側での輻輳予測が必要となる．
輻輳予測に対して，パケットロスが生じる輻輳の前兆として大きなジッタの変化が輻輳
の前後で見られる [16, 17]．従って，輻輳発生の兆候をジッタから検出し，輻輳によるパ
ケットロスが発生するより前に帯域超過を起こす階層に対する Leave 要求が完了すること
で，メディア再生品質を満たすことができる．
3.6.2
Leave Delay に関する議論
既存研究では，受信ノード群が Leave Report を送信した後，実際に受信ノードが属する
サブネットに対してのマルチキャストデータフローが停止されるまでの時間に関して詳細
な議論がされていない．既存研究で問題視されてきた特定レイヤの脱退では，IGMPv1[18]
に関しての考察のみなされてきた．IGMPv1 では，ある Group Address に対する Leave
要求が受信ノードから見て受動的となる．クエリアが一定間隔 (RFC2933 では 60 秒と定
義されている) で配下の受信ノードに対して応答確認を行い，応答が無かった場合に上
位マルチキャストルータに対してデータフローの停止を要求する．そのため，遅延離脱
時間が最大で 60 秒を超えてしまい，輻輳制御機構が効果を発揮し始める時間と，輻輳
が発生している時間に大きなずれが生じてしまう．しかし，IGMPv2[19] では遅延離脱の
問題点に対して，受信ノードの能動的な Leave 要求の発行が追加されている．受信ノー
ドは能動的に Leave 要求を発行し，Leave 要求を受信したクエリアが配下の受信ノード
に対して Group Specific Query を送信することで，Max Response Time(RFC2236 にて
Last Member Query Interval が適用され，1 秒が推奨値と定義されている) で設定された
時間内に受信ノード群から受信継続の要求が無い場合に上位マルチキャストルータに対
してデータフローの停止を要求する．IGMPv2 で追加された，離脱遅延の問題に関して
は，IGMPv3[20]，MLDv1[21]，MLDv2[22] でも同様の手法がとられている．従って，M
を Max Respon Time，t を実際のデータフローがとまるまでの時間，r をクエリアと受信
ノード間の伝送遅延時間，R をクエリアと上位マルチキャストルータの伝送遅延時間とし
た場合，ある Group Address に Join している最後の受信ノードが Leave 要求を発行した
後，実際のデータフローが停止するまでの時間を T は，式 3.2 によって表せる．
T < 0.1 × M + r + R + t
(3.2)
Max Responce Time は最高で 0.1 秒まで低減することが可能なため，遅延離脱と輻輳
時間の大きなずれは発生しない．
23
3.7. FEC 方式の問題点
3.7
FEC 方式の問題点
RLM は通常の IP マルチキャストと比較して，構築した階層に応じてマルチキャスト経
路表エントリが追加されるため，マルチキャストルータに対する負荷が増大する．経路表
エントリ増加の負荷はメモリ利用率の増加，経路表検索時間の増加につながる．従って，
階層化による受信可能なデータ量の粒度と，ルータの負荷がトレードオフの関係になる．
FEC 方式は受信者駆動型，ネットワーク支援型両方をレート制御手法に適用可能であ
る．しかし，FEC 方式 RLM では，パリティ階層も一つのデータ階層として認識されるた
め，通常の RLM と比較して 2 倍の経路表エントリを必要とする．また，FEC を用いた場
合に必ずしも再生品質が満たされないため，FEC を用いない場合の方が輻輳が発生せず，
再生品質が向上する場合が存在する．従って，FEC を用いたストリーミングでは，現状
の利用可能帯域を正しく把握した上で利用される必要があり，輻輳状態に対して必ずしも
有効ではない．
3.8
各手法の動作実績
これまで数多くの階層符号化マルチキャストに関する研究がなされてきた．しかし，実
アプリケーションとして実装されたシステムは存在せず，シミュレーションによる評価が
行われてきた．そのため，研究成果を実サービスへとフィードバックするための評価がさ
れていない．
実ネットワーク上での運用にあたって，現状のネットワーク機器や送受信ノードが持つ
資源，マルチキャストグループ管理，マルチキャスト経路制御に用いられるプロトコルと
の親和性などに関する議論が必要である．
3.9
本章のまとめ
本章では，階層符号化マルチキャストのレート制御手法に関して，RLM，SLM，MLM
の 3 種類があることを述べた．その中で，現状のインターネットにおける大規模同報型
ストリーミング配信には RLM が実際に動作する手法であることを示した．また，RLM
のレート制御の問題点として Estimate Delay と LeaveDelay について議論した．RLM の
レート制御では，メディア品質保証をするために、パケットロスが起こる輻輳の発生を予
測して、未然に超過している帯域分のレイヤを放棄する必要がある．
次章では RLM を動作させるための，受信者のみでできるネットワーク帯域予測につい
て述べる．
24
第4章
ネットワーク帯域予測
3.5 節では本研究が対象とする大規模同報型ストリーミング配信には RLM が適してい
ることを示した．しかし，RLM では受信者が単独でネットワーク状況を把握する必要が
あるため，Estimate Delay が SLM や NLM と比較して長いことを 3.6 節に示した．
本章では，ストリーミングにおける受信者単体で送信者と受信者間のネットワークパス
上での輻輳を検知する手法について検討し，Estimate Delay 短縮のための予備実験と結
果について述べる．
4.1
受信者のみで収集可能なネットワーク情報
ストリーミングでのメディア再生品質を確保するレート制御には，ネットワーク状況の
把握が不可欠である．ネットワーク状況を把握する技術として，最適帯域調査と輻輳検知
が挙げられる．RLM はこれら全ての処理を受信ノードが主体となって行う．
既存の RLM ではパケットロスを指標とした最適帯域調査と輻輳検知手法が提案されて
いる．しかし，ストリーミングに利用される通信プロトコルや受信ノード上で取得可能な
情報を用いることで，パケットロス以外にネットワーク状況を把握する指標となるデータ
を取得できる．一般的なユニキャストを用いたストリーミングアプリケーションでは，受
信者が単独で取得した情報に基づき送信者によるレート制御が行われる [23]．ストリーミ
ングにおいて受信ノードが単独で取得できる情報は，RTP・RTCP SR・UDP・IP などの
ヘッダに含まれる．これらの情報を参照することで取得できるネットワーク状況把握に必
要な情報を以下に示す．
1. パケットロス
RTP のパケットシーケンス番号を参照することで判別可能
2. 送信ノードから受信ノードへの伝送遅延時間
RTCP SR のタイムスタンプを参照することで計測可能
送信ノードと受信ノードの絶対時間の一致が前提となるが，一般的にノードの絶対
時間同期に用いられる NTP の誤差を考慮した計測が必要となる
3. 送信ノード・受信ノード間の往復伝送遅延時間
Ping などの ICMP Echo Reply ソフトウェアを用いることで計測可能
送信ノード遅延時間を除算することで，受信ノードから送信ノードへの伝送遅延時
間を計測可能
25
4.2. 輻輳発生の原因
4. パケットサイズ
受信ノードが受信したパケットのヘッダ上に記述される Packet Length を参照する
ことで取得可能
これらの情報からパケットロスが発生する輻輳の原因を検知することで，パケットロス
に基づく輻輳検知手法と比較して迅速なネットワーク状況把握が可能となる．パケットロ
スは輻輳発生の後に発生するため，迅速な輻輳検知は Estimate Delay の短縮を意味する．
また，最適帯域調査をネットワーク状況に基づいて行うことで，Join Experiment 方式が
用いる根拠の無い階層増加を抑制し，再生品質の保護につながる．
4.2
輻輳発生の原因
インターネット上でのパケットロスは，送信ノードと受信ノード間のパス上でボトル
ネックとなるリンク上の輻輳が主な原因である．ネットワーク状況を示す情報を有効活用
するためには，輻輳発生のメカニズムを正しく捉える必要がある．
以下に輻輳とパケットロス発生のメカニズムを示す．
1. 中継 (受信) ノードの中継 (受信) 性能を超えるパケット入力が発生する
2. パケットが中継 (受信) ノードのネットワークインターフェースキューにキューイン
グされ輻輳が発生する
3. 中継 (受信) ノードのインターフェースキュー長を超える入力が発生し，パケットロ
スが発生する
輻輳状態においてパケットロスが発生するメカニズムを図 4.1 に示す．Routing Service
Resource(S) は一定パケット転送処理性能を持つとした場合，その転送処理性能を上回る
パケット数を転送処理する必要が出た場合に各ネットワークインターフェースキューに
パケットが格納される．図中 eth2 ではネットワークインターフェースキューにこれ以上
パケットを格納できない状態にあり，図中の状態から追加パケットが eth2 に流入した場
合，追加パケットが破棄されパケットロスが発生する．また，破棄されるパケットはネッ
トワークインターフェースキュー長を超えた後のパケットであるため，drop-tail 方式のパ
ケット破棄と呼ばれる．
4.3
パケットペア理論
パケットペア理論は輻輳発生のメカニズムを利用し，中継ノードが公平待ち行列を利用
していることを前提として，パス上のボトルネックリンク帯域を推測する手法である [24]．
この手法では，送信ノードから受信ノードへの伝送遅延時間とパケットサイズに着目して
帯域推測を行う．図 4.2 にパケットペア理論の概要図を示す．
26
第 4 章ネットワーク帯域予測
!
$#
%&'
%&,
(&*)
%&+
*6
"
$ 289 :2%34%
; &*:%234%
7* &' /.*
%&)-.*
%&%, /.*
12%34%5
%&+0 /.*
図 4.1: パケットロス発生メカニズム
Sender
Receiver
packet pair
data1
data2
T
Ack
T
Ack
図 4.2: パケットペア理論の概要図
パケットペアでは，送信ノードはペアとなる計測パケットを連続して送信する．公平待
ち行列法では，コネクション毎にキューが割りあてられるため，ペアとなっているパケッ
トはペアを崩すことなくキューイングされる．キューイングされたパケットはボトルネッ
27
4.4. 輻輳メカニズムのモデル化
クリンクを通過する際，中継ノードは中継性能を超過しているため，パケットの間隔が
広がる．受信ノードは計測パケットの受信と同時に送信ノードに対して Ack を送信する．
Ack パケットの間隔は，データパケットに対して十分小さいため，ボトルネックリンクに
おいて拡大しないことを前提とする．この理論から，パケットペアでは送信ノードが送信
したデータパケットサイズ S とし，RTT の時間差 R とした場合，式 4.1 によってボトル
ネックリンクの帯域 T を算出する．
ボトルネックリンクの帯域 (byte/sec) =
データパケットサイズ (byte)
T (sec)
(4.1)
しかし，公平待ち行列法に基づいたパケット転送を行う中継ノードの実装は少なく，実
際のネットワーク機器は FIFO キューによる実装が主流である．また，計測パケットの損
失による計測の失敗や，受信ノードから送信ノードへの伝送遅延時間の揺らぎなど，計測
結果に誤差を生む要因が多い．
パケットペア理論の応用としてこの問題を解決するアプリケーションに bprobe がある
[25]．bprobe では FIFO キューを用いるネットワーク機器上において，パケットペア理論
を活用するために，パケットペアが持つ問題点を以下の手法で解決している．
• 他のパケット割り込みによるパケット間隔の拡大
連続的に転送するパケット数を増やす
• 計測パケットの喪失，破損
複数回計測を行なう
• 受信側からの Ack パケット側の通信経路の輻輳
計測回数を複数回とする
解析結果によると，広域でボトルネックリンクの帯域が大きな場合に若干精度が低下し
たが，主に± 20%の範囲に 80%から 90%程度の計測値が存在することが報告されている．
bprobe の計測結果の報告より，計測サンプル数を増加させることにより計測精度を高め
ることができる．
4.4
輻輳メカニズムのモデル化
パケットペア理論や TCP-Friendly から，4.1 節で述べたネットワーク状況を指し示す情
報を利用することで，最適帯域予測・輻輳検知が可能であることが分かる．本節では，一
般的な中継ノード実装で用いられている FIFO キューと drop-tail によるパケットロスを
前提として，待ち行列モデルを用たい輻輳とパケットロスのメカニズムをモデル化する．
モデルから IP マルチキャストを用いたストリーミングにおいて，受信者単体で取得可能
な帯域予測および輻輳検知に利用可能な情報を検討する．
28
第 4 章ネットワーク帯域予測
待ち行列モデルでは，ケンドールの記号によって待ち行列におけるトランザクションの
到着するシステムの特徴が示される．ケンドールの記号では待ち行列を以下にしめす 4 つ
の要素を基に A/B/C/d と表現される．
• A: トランザクションの到着分布
• B: サービス時間の分布
• C: 窓口数
• d: 行列の有無と長さ (0 の場合は省略可能)
また，A と B の分布形態としては，以下の記号が用いられる．
• M: ポアソン分布または指数分布
• D: 一定分布
• Ek: k 次のアーラン分布
• G: 一般分布
インターネット上の中継ノードとなるネットワーク機器は，1 個以上のネットワークイ
ンターフェースを持ち，各インターフェースはインターフェースごとに異なるキュー長を
持つ．また，インターフェースの集合に対して 1 個のルーティング・フォワーディングエン
ジンを持つ．パケットの到達率は規則性の無いランダム到着率が適用されるため，一般的
に指数分布が用いられる．従って，インターネットにおける中継ノードの待ち行列モデル
は，
「M /M /1/m(パケット到着率が指数分布/処理時間が指数分布/ルーティング・フォワー
ディングエンジン 1 個/キュー長 m)」と表すことができる．文献によっては「M /D/1/m」，
「M /M /1/∞」とモデル化される場合もあるが [26, 27]，インターネット上の中継ノード
は ATM などサービス時間分布が一定分布となるものだけではない．また，キュー長が ∞
の中継ノードは現実的に存在しないため考慮しない．
待ち行列モデルでは，平均到着率λはトランザクションの平均到達間隔 (パケットの平
均到達間隔) を ta とした場合，式 4.2 と表される．
λ=
1
ta
(4.2)
また，単位時間あたりに処理可能なトランザクション (パケットルーティング・フォワー
ディング) μは窓口の平均処理時間を ts とすると，式 4.3 となる．
µ=
29
1
ts
(4.3)
4.4. 輻輳メカニズムのモデル化
従って，サービス利用率 p は，式 4.4 と式 4.5 で表される．
p = λ ts =
p=
λ
µ
ts
ta
(4.4)
(4.5)
ネットワーク上にノード A と B が存在し，ノード A と B 間には 1 つ以上の中継ノード
が存在する場合，ノード x が n 番目のパケットを送出した時間を SendT imex,n と定義し，
送出したパケットを P acketx,n と定義する．ノード y が n 番目のパケットを受信した時間
を RecvT imex,n と定義する．ノード A はノード B に対して間隔 SendInterval でパケッ
トを送出した場合，式 4.6 となる．
SendT imeA,n+1 − SendT imeA,n = SendInterval
(4.6)
中継ノード上で輻輳が発生せず，式 4.7 が満たされる場合，一定時間でパケット処理が
行われた場合，式 4.8 と式 4.9 と理論的にはなるが，実ネットワーク上では，式 4.10 と式
4.11 に示すように，パケット到達間隔に揺らぎが発生する．
p<1
(4.7)
RecvT imeA,n+1 − RecvT imeA,n = SendInterval
(4.8)
RecvT imeA,n+2 − RecvT imeA,n+1 = SendInterval
(4.9)
RecvT imeA,n+1 − RecvT imeA,n = SendInterval + ∆tn
(4.10)
RecvT imeA,n+2 − RecvT imeA,n+1 = SendInterval + ∆tn+1
(4.11)
∆tn と ∆tn+1 の差は，中間ノード上でのルーティング，フォワーディングが一定時間で
終了しなかった場合を示し, この差をパケット到達間隔のジッタ (以下ジッタ) と呼ぶ．一
般的にジッタの原因は輻輳によるパケット処理能力の超過，すなわち式 4.12 が満たされ
た場合に発生する．
p>1
(4.12)
ジッタ発生の原因である輻輳，すなわちルーティングおよびフォワーディング処理の超
過を待ち行列モデルを基にモデル化する．サービス利用率 p は，トランザクション数が n
個ある場合，4.13 となる．
p = (λa + λb ... + λn ) ts
30
(4.13)
第 4 章ネットワーク帯域予測
従って，ネットワークインターフェース a に割りあてられる処理時間を tsa とし，式
4.14 が満たされる場合，ネットワークインターフェース a のキューにパケットが蓄積され
パケット間隔が開く．
p < 1 かつ µa > λa tsa
(4.14)
また，ネットワークインターフェース a のキュー長を ma とし，到着パケットの平均長
を P とした場合，式 4.15 が満たされる場合，ネットワークインターフェース a のキュー
長が不足し，以後のパケットが drop-tail され，パケットロスとなる．
p > 1 かつ ma < λa × P
(4.15)
従って，式 4.16 が満たされる場合，サービス (ルーティング・フォワーディング) 性能に
対して，過剰なトランザクション (トラフィック) が流入すると輻輳が発生し，パケットが
ネットワークインターフェースキューにキューイングされジッタが発生する．そのため，
平均処理時間の誤差を超える大きなジッタが発生した場合は，パケットロスの前兆として
予測検知できる．
p > 1 かつ ma > λa × P
4.5
(4.16)
パケットフロー観測手法とパケットロス予測
送信ノードでのパケット送信間隔を一定にすると，受信ノードにおけるパケット到達
間隔からジッタを観測することができる．この手法をパケットフロー観測手法と呼ぶ．図
4.3 にフロー観察手法の概要を示す．受信ノードは送信ノードから転送されたストリーム
データパケットの間隔をパケットを受信毎に比較する．送信ノードがパケット送信時間を
一定にすることを前提とすることで，パケットの間隔が伝送遅延時間の揺らぎであるジッ
タとして計測可能である．
しかし，パケット到達遅延時間におけるジッタ成分の理論値は 0 であるが，実際の機器
上では中継ノードにおけるルーティング時間・パケットフォワーディング時間や送信ノー
ド上でのパケット送信処理時間は一定ではないため，確実に理論値とはならない．そのた
め，ジッタ値と輻輳状態の相関関係に対してジッタ閾値を設定する必要がある．理論値と
の誤差を考慮した閾値設定には以下の 2 点を厳守することが重要である．
• 計測回数の多さ
• 受信ノード上での統計的な計測
31
4.6. 予備実験概要
sender
Receiver
TT
図 4.3: パケットフローの観察
ストリーミングでは一般的にパケット数が多く，CBR(Constant Bit Rate) メディアフォー
マット送信ではバースト転送を避けるため，パケット送信間隔が一定であることが理想
となる [28, 29]．また，VBR(Variable Bit Rate) メディアフォーマットにおいても，荒い
時間粒度で計測した場合には，CBR となるため同様である．また，送信ノードは計測パ
ケットの送受信を行うことが無く通常のストリーミング送信と比較して負荷に変化が無
いため，IP マルチキャストとの親和性が高い．統計的な解析を行うことで，ジッタとパ
ケットロスの相関関係を調査可能である．また，統計的なジッタ観測によって，輻輳によ
るパケットロスの発生を検知可能なジッタの値に閾値を設定できる．
パケットフロー観測手法の場合，輻輳が発生しパケットロスが発生する前にパケット到
達遅延に大きなジッタが見られるが，その時間は 1 秒未満である [16, 17]．しかし，これ
らの文献では伝送遅延時間の分散とパケットロスの関係や異なる伝送遅延時間上における
ジッタとパケットロスの相関などの調査がなされていない．そのため，本研究では予備実
験よりジッタ値・伝送遅延時間・パケットロスの因果関係を調査する．
4.6
予備実験概要
4.4 節で行った輻輳メカニズムのモデル化の正当性とジッタ・伝送遅延時間・パケット
ロスの因果関係を調査するため，図 4.4 に示すネットワークトポロジ上でのユニキャスト
通信を用いて実験を行った．
調査アプリケーションには DVTS を用い，送信ノードには FreeBSD の Device Polling 機
能を用いることで可能な限り一定間隔でパケットを送信する設定を行った．また，擬似的
な帯域制御と遅延時間制御に DUMMYNET を用いた．パケットロスの調査には DV デー
タが格納されている RTP パケットのシーケンス番号を利用し，伝送遅延時間には RTCP
SR パケットの NTP タイムスタンプを用いた．そのため，伝送遅延時間を示す RTCP SR
がパケットロスする場合があるが，実ネットワーク上と同様に drop-tail されるパケットに
32
第 4 章ネットワーク帯域予測
規則性が無いため特別な処理を行わずに利用した．利用した機材を表 4.1 に示し，表 4.2
に実験を行ったネットワークパターンを示す．
表 4.1: 利用機材
受信機器
送信機器
型番
CPU
メモリ
OS
NIC
富士通 LOOX T70GN
Intel Pentium M 1GHz
512MByte
FreeBSD 5.4 Release
RealTech 100BaseTX
伝送遅延時間
10 ミリ秒
30 ミリ秒
60 ミリ秒
90 ミリ秒
富士通 LOOX T70GN
Intel Pentium M 1GHz
512MByte
Linux Kernel 2.4.27
RealTech 100BaseTX
DUMMYNET
DELL PE1850
Intel Xeon 3.60GHz
3GByte
FreeBSD 5.4 Release
Intel 1000Base-T
表 4.2: ネットワークパターン
輻輳前の帯域輻輳時の帯域輻輳収束時の帯域
100Mbps
100Mbps
100Mbps
100Mbps
20/24/27Mbps
20/24/27Mbps
20/24/27Mbps
20/24/27Mbps
100Mbps
100Mbps
100Mbps
100Mbps
( +*,-,. /01*2) 13
4 *56$1+*7+89
!"$#&%')(
図 4.4: 実験トポロジ図
33
4.7. ジッタとパケットロスの相関
4.7
ジッタとパケットロスの相関
図 4.5，図 4.6，図 4.7 に伝送遅延時間がそれぞれ 10，30，60 ミリ秒で輻輳時の帯域を
100Mbps から 20Mbps にシェーピングした場合の調査結果を示す．また，図 4.8 に伝送遅
延時間が 10 ミリ秒で輻輳時のパターンを 100Mbps から 20Mbps へシェーピングし，その
後 25Mbps へパラメータを変えた場合を示す.
各図の左縦軸はジッタ値を示し，
「+」がジッタ値を表す. 右縦軸は欠損したパケット
数を示し，折線が欠損したパケット数を示す. 横軸は受信した RTP パケット数を示して
いる．
図 4.5，図 4.6，図 4.7 からジッタ値の上限値はほぼ同一値となり，伝送遅延時間とジッ
タの値に関連性が無いことが分かる. これは式 4.15 と式 4.16 に示した輻輳状態における
伝送遅延時間の増加がネットワークインターフェースキュー長に依存しすることに起因す
る. サービス利用率が 1 を超えた場合にキュー長を超えるパケット入力が発生した時にパ
ケットが drop-tail されるため，受信ノードまで到達するパケットのジッタ値の絶対値は
ネットワークインターフェースキュー長によって決定される. しかし，ボトルネックリン
クのネットワークインターフェースキュー長を固定値として定義できないため，固定の
ジッタ値をもってパケットロスの指標と定義できない. そのため，ボトルネックリンクの
ネットワークインターフェースキュー長に基づくジッタ値の分散の閾値を設定する必要が
あるが，全く輻輳が発生しない状態から閾値を設定することはできない．
図 4.5 に示した伝送遅延時間 10 ミリ秒で，100Mbps から 20Mbps にシェーピングした
場合のグラフを状態別に図 4.9，図 4.10，図 4.11，図 4.12 に示し，輻輳発生前後のネット
ワーク状況を示す．図 4.9 は DVTS で利用されるネットワーク帯域に対して十分な帯域が
確保されている定常状態である．ほとんどのパケット到達間隔に差が無く，中継ノード上
でのサービスに十分な処理能力があることを示している．図 4.10 では図 4.9 と比較して
ジッタ値が分散し，ジッタの最大値が上昇している．この上昇分はキューイングによる遅
延時間である．図 4.11 では輻輳状態からパケットロスが発生している．この時ジッタ値
が急激に増加するのは，パケットロスによって本来一定間隔で到達するべきパケットが欠
損するためである．図 4.12 ではジッタの分散が定常時とほぼ同一状態になり，輻輳状態
が解消したことを示している．
4.8
伝送遅延時間とパケットロスの相関
伝送遅延時間とパケットロスのグラフから相関を検証する．図 4.13，図 4.14，図 4.15 に
伝送遅延時間が 60 ミリ秒で，輻輳時の帯域を 100Mbps からそれぞれ 20Mbps，24Mbps，
27Mbps にシェーピングした場合の調査結果を示す．また図 4.16 に伝送遅延時間が 10 ミリ
秒で，輻輳時の帯域を 100Mbps から 20Mbps にシェーピングした場合の調査結果を示す．
各図の左縦軸は伝送遅延時間 (ミリ秒) を示し，
「＋」が伝送遅延時間値を表す. 右縦軸
は欠損したパケット数を示し，
「×」が欠損したパケット数を示す. 横軸は受信した RTP
パケット数を示している．
34
第 4 章ネットワーク帯域予測
600
-200
40
jitter
50
30
-400
70
200
60
0
50
-200
40
30
-400
20
-600
80
400
pktloss
60
0
90
600
70
200
100
Jitter
Packet Loss
800
90
80
400
jitter
100
pktloss
Jitter
Packet Loss
800
20
-600
10
10
-800
-800
0
2000
4000
6000
8000
packetnum
10000
12000
14000
0
16000
0
2000
4000
6000
8000
10000
packetnum
12000
14000
16000
0
図 4.5: 伝送遅延 10 ミリ秒で 100Mbps から図 4.6: 伝送遅延 30 ミリ秒で 100Mbps から
20Mbps にシェーピングした場合
20Mbps にシェーピングした場合
600
50
40
jitter
0
-200
30
-400
70
200
60
0
50
-200
40
30
-400
20
-600
80
400
pktloss
60
90
600
70
200
100
Jitter
Packet Loss
800
90
80
400
jitter
100
pktloss
Jitter
Packet Loss
800
20
-600
10
10
-800
-800
0
2000
4000
6000
8000
10000
packetnum
12000
14000
16000
0
18000
0
2000
4000
6000
8000
10000
packetnum
12000
14000
16000
18000
0
図 4.7: 伝送遅延 60 ミリ秒で 100Mbps から図 4.8: 伝送遅延 10 ミリ秒で 100Mbps から
20Mbps にシェーピングした場合
25Mbps，20Mbps までシェーピングした場合
600
600
50
40
30
90
70
200
60
0
50
-200
40
30
-400
20
-600
jitter
0
-200
pktloss
60
100
80
400
70
200
-400
Jitter
Packet Loss
800
90
80
400
jitter
100
20
-600
10
10
-800
-800
0
500
1000
packetnum
1500
0
2000
4000
4200
4400
4600
4800
packetnum
図 4.9: 定常時
図 4.10: 輻輳発生時
35
0
5000
pktloss
Jitter
Packet Loss
800
4.8. 伝送遅延時間とパケットロスの相関
100
600
-200
40
jitter
50
pktloss
jitter
60
0
30
-400
70
200
60
0
50
-200
40
30
-400
20
-600
80
400
70
200
90
600
80
400
100
Jitter
Packet Loss
800
90
pktloss
Jitter
Packet Loss
800
20
-600
10
10
-800
-800
6000
6500
7000
packetnum
0
8000
7500
10000
10200
図 4.11: 輻輳によるパケットロス発生時
10400
10600
10800
packetnum
11000
11200
11400
0
図 4.12: 輻輳収束時
全体の伝送遅延時間は環境によって異なるが，輻輳時の追加遅延時間はほぼ一定となっ
た. また，伝送遅延時間の増加が発生する時間とパケットロスを観測する時間がほぼ同一
となった. パケットロスの発生と同様に，輻輳収束によるパケットロスの解消と定常状態
の伝送遅延時間に戻る時間がほぼ同一となった．
RTCP SR パケットと RTP パケットのサンプル数が大きく異なるため，この図からそ
の特徴を因果関係を導き出せない．しかし，輻輳メカニズムのモデル上では drop-tail さ
れずキューイングされたパケットは，サービスに対しての入力数が一定の場合同一の値に
なるため，欠損したパケット数と到達したパケットの伝送遅延時間には関連性が無い．
従って，伝送遅延時間の統計的計測は，輻輳発生の検知にはジッタ値の観測と比較して
輻輳発生を早期発見できないが，輻輳の収束を示す値を示す．そのため，ジッタ値の分散
の収束・パケットロスの解消・伝送遅延時間の収束を組み合わせることで精度の高い輻輳
収束予測ができる．
100
Delay
Packet Loss
100
80
80
100
Delay
Packet Loss
90
90
80
80
70
70
40
60
delay
50
40
60
pktloss
60
delay
60
50
40
40
30
20
30
20
20
20
10
0
0
2000
4000
6000
8000
10000
packetnum
12000
14000
16000
pktloss
100
10
0
0
0
2000
4000
6000
8000
10000
packetnum
12000
14000
16000
0
図 4.13: 伝送遅延 60 ミリ秒で 100Mbps から図 4.14: 伝送遅延 60 ミリ秒で 100Mbps から
20Mbps にシェーピングした場合
24Mbps にシェーピングした場合
36
第 4 章ネットワーク帯域予測
100
50
Delay
Packet Loss
80
20
"Delay"
Packet Loss
40
100
90
80
70
10
50
20
pktloss
delay
40
60
jitter
30
pktloss
60
40
30
20
10
20
10
0
0
2000
4000
6000
8000
10000
packetnum
12000
14000
16000
0
0
0
2000
4000
6000
8000
packetnum
10000
12000
14000
0
16000
図 4.15: 伝送遅延 60 ミリ秒で 100Mbps から図 4.16: 伝送遅延 10 ミリ秒で 100Mbps から
27Mbps にシェーピングした場合
20Mbps にシェーピングした場合
4.9
考察
ジッタ値の分散の急激な変化は輻輳と輻輳収束の前兆であることを 4.7 節に示した．し
かし，ジッタ値の上限はボトルネックリンクのネットワークインターフェースキュー長に
依存するため，ジッタ値の変化量とパケットロスの相関を固定値で決定することはでき
ない．
輻輳による伝送遅延時間の増加を 4.8 節に示した．伝送遅延時間の増加量はボトルネッ
クリンクのネットワークインターフェースキュー長に依存するため，サービスに対する入
力量が一定の場合，全体の伝送遅延時間に依存せずほぼ一定となる．また，伝送遅延時間
の増加はパケットロスの発生とほぼ同じタイミングで発生するため，輻輳収束を判断する
指標として追加利用することで信頼性が高まる．
受信者単体による計測をモデル化することで、ジッタ値と伝送遅延時間の増加量はネッ
トワークインターフェースキュー長に依存するとした場合，中継ノード上で輻輳検知を行
う手法との輻輳検知時間の差が算出できる．中継ノード上では各ネットワークインター
フェースキューを監視し，一定量パケットが蓄積されることで輻輳を検知する．また，パ
ケットがキューイングされた時点からジッタ値の分散の変化が発生する．従って，受信
ノード上で輻輳と判断するための閾値設定手法に依存するが，中継ノード上でパケットが
キューイングされ輻輳が発生した場合，その影響であるジッタ値の分散の変化が受信ノー
ドに伝達される時間は，ボトルネックリンクを持つ中継ノードから受信ノードへの伝送遅
延時間と定義できる．
以上の考察より，輻輳発生を早期に検知するにはジッタ値の分散の変化を監視し，パ
ケットロス発生につながる閾値設定が必要となる．また，輻輳収束の検知にはジッタ値の
分散の収束・伝送遅延時間の収束・パケットロスの収束を用いることで，パケットロスの
みを指標とした場合と比較して迅速かつ正確に判断できる．
37
4.10. 本章のまとめ
4.10
本章のまとめ
本章では，既存の RLM が抱える Estimate Delay の短縮を目標として，受信者単独で可
能な輻輳検知手法を検討した．受信者単体で取得可能なネットワーク状況を示すデータを
整理し，輻輳とパケットロスのメカニズムを公平待ち行列モデルによってモデル化した．
モデル化からジッタ値と伝送遅延時間に着目し，RLM の通信モデルに準じた計測手法と
してパケットフロー観測手法を挙げ，実験結果からモデルの正当性と実験結果の考察を
行った．考察より，輻輳検知にジッタ値の分散を用い，輻輳収束検知にジッタ値の分散・
伝送遅延時間・パケットロスの値に着目することでパケットロスのみを監視した場合と比
較して，迅速かつ正確に判断可能であることを示した．
次章では，パケットフロー観測手法を用いた RLM ストリーミングの提案と DVTS を応
用したシステムの設計について述べる．
38
第5章
パケットフロー観測を用いた
RLM の提案と DVTS への応用
本章では，3.5 節で述べた LM の既存研究の問題点を整理する．解決手法として，第 4
章で明らかにしたジッタ・遅延時間・パケットロスの関係を RLM の最適帯域探索手法へ
の応用する手法を提案し，他の関連研究と比較した本手法の優位性を述べる．
本手法の評価に対して適しているストリーミングソフトウェアに関する議論を行い，
DVTS との親和性について述べる．また，本手法を DVTS に応用するにあたり本送信ノー
ド側，受信ノード側システムの要件事項を整理し，パケットフロー観測を用いた RLM ス
トリーミング機構の設計を行う．
5.1
問題点の整理
RLM は SLM や NLM と比較して輻輳発生からレート制御による最適レートへの収束時
間が長い．しかし，RLM は既存の IP マルチキャスト経路制御モデルに変更が必要なく，
ディストリビューションツリーが簡単に構築できる．また、RLM は，負荷を多数存在す
る受信ノード群に分散し，送信ノード，中継ノードに対しての負荷が最も低い．そのため，
RLM は最も規模性に優れた LM レート制御モデルである．
本研究では大規模同報型ストリーミング配信を対象とするため，最も重要視すべき指
標は規模性である．そのため，LM のレート制御主体を受信ノード群とする RLM が適し
ている．しかし，RLM の輻輳検知手法である Join Experiment 方式では，パケットロス
の検知をトリガーとするために発生する Estimate Delay と，RLM のモデル上必ず発生す
る Leave Delay が，メディア品質を低下させる長時間の輻輳収束時間として問題視されて
きた．
この問題に対し，Estimate Delay の短縮，受信者駆動の IP マルチキャスト上での輻輳
検知，およびパケットロス予測を行うことで，RLM においてメディア品質の低下を予防
可能なレート制御手法を実現する．
Leave Delay に関しては，既存の IP マルチキャストにおけるグループ管理プロトコル，
経路制御プロトコルに依存する．クエリア，中継ノードの機器設定に依存して遅延時間が
変化するため，Leave Delay は運用ポリシーに依存する．そのため，本研究が解決すべき
問題として考慮しない．
39
5.2. パケット観測を用いた RLM の提案
5.2
パケット観測を用いた RLM の提案
RLM のモデル上で Estimate Delay を既存手法より短縮するには，パケットロスを受信
ノード上で観測するよりも前に輻輳検知を行う必要がある．また，メディア品質を低下さ
せないためには，パケットロスに先立った輻輳検知をトリガーと，アプリケーションへパ
ケットロス予測の通知を行う必要がある．従って，受信ノードが単体でパケットロスに先
立った輻輳検知が必要となる．パケットロスに先立つ輻輳検知手法として，パケット観測
手法によるジッタ，およびパケット到達遅延時間の統計的な計測が有効であることを第 4
章で示した．
パケット観測手法を RLM のモデルに適用することで，送信ノード，中継ノード，クエ
リアに対して新たな負荷を追加することなく，Estimate Delay の短縮，およびメディア品
質低下の回避が可能となる．
図 5.1 に RLM における従来の最適帯域探索・レート制御手法と本手法の違いを示す．
'!$#%'!(D*
DLM
"!$#&%'!)(*
DOPQR
"!)#'%!)(D* E 9GFH !GI FJ 9&K !
,+ .-/
"!$#&%'!)(*
103246587'9: ;)<>=1?@
A CB D?@
+ >-N
図 5.1: 従来手法と提案手法の比較
従来 Join Experiment 方式では，パケットロスをトリガーとした Leave 要求の発行に
よってレート制御を行っている．しかし，この手法ではメディアの再生品質が一時的に低
下した後のレート制御を行うことになる．
本手法では，パケットロスの前兆となるジッタ，パケット到達遅延を統計的に解析し，
パケットロス発生の前兆となるジッタの値に閾値を設定する．閾値を超えるジッタを検出
40
第 5 章パケットフロー観測を用いた RLM の提案と DVTS への応用
した際は，パケットロスに先立って最上位のレイヤの Group Address に対して Leave 要
求を発行することで，Join Experiment 方式と比較して Estimate Delay を短縮できる．ま
た，パケットロスの前兆をアプリケーション層に通知することで，再生品質を低下させる
メディアデータを除外したメディア再生要求を通知できる．
5.3
本研究における DVTS の位置づけ
本研究で提案する手法の実現にあたって重要となる点を以下に挙げる．
1. ストリーミングメディアとして階層化可能なメディアフォーマットを用い，階層化
に必要な計算量が少ないこと
2. 細かな粒度でメディアフォーマットを階層化でき，各階層のビットレートが等しい
こと
1 点目は，フロー測手法の前提となるパケットの一定送信間隔を阻害する要素を除外す
るためである．2 点目は，実ネットワーク上の中継ノードにおける IP マルチキャスト経
路制御に対する負荷計測を行うためである．これらの条件を満たすストリーミングシステ
ムとして，本研究では DVTS に着目した．
5.3.1
DVTS
DVTS は，IEEE1394 インタフェースから DV(Digital Video) フォーマットのストリー
ムを取得し，そのストリームに対し IP データグラム化を行い，インターネットを介して映
像・音声の転送を行うシステムである．このシステムを利用することにより，リアルタイ
ムに SD(Standard Definition) 映像の配信が可能である．DVTS は IP マルチキャスト対応
において，ASM と SSM 両方に対応している．またユニキャストを用いた場合に，ECN，
TCP-Friendly，RTCP を用いたレート制御が先行研究として行われてきた [23, 30, 16, 17]．
提案手法の評価を行うために，DVTS に階層化マルチキャスト機能，および IP マルチ
キャスト上でのレート制御機能を追加した Layered DVTS を実装する．なお，データ送信
ノードが単一のメディア配信を対象とした研究であるため，IP マルチキャストでは SSM を
対象とする．また，本手法は RLM であるため，RTCP の宛先を IP マルチキャスト Group
Address として活用する．
5.3.2
Digital Video フォーマット
フレーム内圧縮方式である DV フォーマットは，DCT(Discrete Cosine Transform) と
VLC(Variable Length Coding) を 1 フレーム毎に利用した定レートの圧縮を行っている．
従って，DV フォーマットでは必ず個々の映像フレームが同一データサイズであると保障
41
5.3. 本研究における DVTS の位置づけ
できる．そのため，DVTS では送信ノードでのエンコード処理が必要なく，全てのフレー
ムが同一データサイズとなるため，DVTS は本手法の実装，および評価に適している．
DV フォーマットは，フレーム単位で抽象化されたフォーマットで，全てのデータ (映
像，音声，システムデータ) はビデオフレーム単位で扱われる．フレーム単位で映像と音
声を同時に扱う事により，音声と映像の同期などの問題が解決されている．
DV データは，3 段階の階層構造で扱われる．DV フォーマットにおける階層構造を図
5.2 に示す．ビデオフレームデータは複数の DIF(Digital Interface Format) Sequence に分
割される．DIF Sequence は 150 個の DIF Block に分割され，各 DIF Block は 80byte とな
る．DIF Block は，DV データにおける基本構成単位であり，全ての DV 仕様で利用され
ている．
2.7 節で述べた通り，デジタルメディアデータの階層化は解像度だけでなくフレームレー
トや色階調など，様々な画像品質をメトリックとすることで実現可能である．DV の音声
を Base Layer として，映像フレームを任意の階層数に分割することで，フレームレート
をメトリックとした階層化できる．また，映像フレームで階層化した場合，最大 31 段階の
階層を構築可能であり，各 Enhanced Layer のデータビットレートが同一となる．従って，
約 1Mbps 単位の階層化が可能なため，粒度の細かいメディア品質管理が可能となる．し
かし，フレームレートの急激な変化は再生品質を低下させる原因となる．Layered DVTS
では均一なフレームレートを実現するため，映像階層の最小構成単位を 1/N レートとし
て定義した．
Data in one video frame
DIF sequences
DIF
Sequence 0
Structure of a DIF
sequence
Header
Section
DIF blocks
Structure of a
DIF block
DIF block
0
0
3
DIF
Sequence 1
Subcode
Section
DIF block
1
..........
VAUX
Section
DIF block
2
DIF block
3
Audio and Video
Section
..........
Byte position number
ID
DIF
Sequence (n-1)
DIF block
148
DIF block
149
79
Data
n = 10 for 525-60 system
n = 12 for 625-50 system
図 5.2: DV フォーマット
42
第 5 章パケットフロー観測を用いた RLM の提案と DVTS への応用
5.4
Layered DVTS の設計概要
DVTS に階層化マルチキャスト機能，パケットフロー観測による帯域制御機構を拡張実装
する Layered DVTS の設計について述べる．DVTS では送信ノード側プログラム (dvsend)
と受信ノード側プログラム (dvrecv) で必要となる拡張機能が明確に異なる．DVTS の基
本的なプログラムに対する追加機能を，拡張対象のプログラム毎に以下にまとめる．
• 送信ノード側 (dvsend) に必要となる機能
– DV データの階層化
– 階層化されたデータの IP マルチキャスト送信
– 送信間隔の平滑化
• 受信ノード側 (dvrecv) に必要となる機能
– 階層化された受信データの再構成
– パケットフロー観測による輻輳検知
– 輻輳検知をトリガーとしたレート制御
拡張実装する機能と，DVTS の基本的な機能を組み合わせた設計概要を図 5.3 に示す．
送信ノードでは，IEEE1394 デバイスドライバより DV データを読み込み，指定された階
層数に応じてフレーム数をメトリックに階層化する．階層化された各データブロックは指
定された Group Address と結び付けられた独立したソケットから，IP データグラム化さ
れ出力される．その際，音声データを受信ノードが必ず受信する Base Layer として扱い，
音声データは常に一定間隔でのデータ送信を行う．
受信ノードでは，指定された Group Address をクエリアに対して徐々に Join 要求を発
行する．音声データの Base Layer においてパケットフロー観測を行い，ジッタ，および
遅延時間とパケットロスの相関を導き出す．各ソケットから受信された DV データの断片
を再構築し，IEEE1394 デバイスドライバへ書き込み，映像出力を行う．
5.5
階層化されたデータの分割送信
受信ノードでパケットフロー観測を行い，ジッタを参照値として用いるためには，送信
ノードでの一定間隔パケット送信が不可欠となる．全ての受信ノードにおいて受信される
Group Address を持つストリームがその対象となるため，本システムでは Base Layer と
して扱う音声データのパケットを一定間隔で送信することとする．
また，フレーム数を基調とした映像データの階層化を行うが，IEEE1394 インターフェー
スからの入力に従った IP パケットの送信はバースト転送を発生させる．特に，送信ノー
ド側での階層化と比較して，少ない階層数のみを受信する受信ノード側でのバースト転送
によって，パス上に位置する中継ノード上のネットワークインターフェースキュー長を一
時的に枯渇させる可能性が増加し，輻輳が発生しやすくなる．
43
5.6. 受信ノード上での輻輳検知とレート制御
A?BDCFEHGI9EJBKAML6EDB
N COPBDQC(B-O
RSBUTBDL VFBWGMIJEJBKAXLYEJB
;;<;#"&=>?$@+ : @
;;<;#"&=>?$@+ : @
Z '() !"
!"$#
!"%
!"&
./ 0
12) )
*+
!
-, + 5$
6
879:
3$4 / ) '() !
!"#
!")%
!")&
図 5.3: 設計概要
そのため，各 Enhanced Layer は一時的なバッファリングを行いトラフィックの平滑化
を行う．図 5.4 に IEEE1394 インターフェースからのデータ入力に従った階層化データの
分割送信を，図 5.5 に一時的にバッファリングを行いバースト転送を抑制した階層化デー
タの分割送信を示す．
送信ノードが 3 つの Enhanced Layer を送信し，受信ノードでは 2 つの Enhanced Layer
のみ受信している状態を示している．この場合，図 5.4 では，パケット転送が高密度で持
続する場合と，全く転送されない時間が発生するのに対し，図 5.5 では，パケット転送が
低密度で継続的に一定レートに近い転送が行われている．図 5.5 に示した手法を用いる場
合，バッファリング容量と共に伝送遅延が増加するが，図 5.4 に示した手法との差分は階
層数分のフレーム数が再生される時間のみとなる．本研究では伝送遅延時間の増加と比較
してメディア再生品質を優先するため，後者の手法を用いる．
5.6
受信ノード上での輻輳検知とレート制御
受信ノード単体で参照できるネットワーク状況を示す値として，伝送遅延時間，ジッタ，
パケットロス数が挙げられる．Layered DVTS では受信ノード側でのパケットフロー観測
手法を用いてこれらの値を取得し，輻輳予測を行う．また，輻輳予測に基づき受信ノード
単体で受信対象とする階層数を変化させ，レート制御を行う．以下に，セッション開始時
からの状態遷移を示し，各状態における動作概要を示す．
1. 利用可能帯域幅の算出
44
第 5 章パケットフロー観測を用いた RLM の提案と DVTS への応用
G JKML!NOLPQG HI
3
5 46
789
:;
<=
6>?
RTSVUXWZY\[]W]S^R`_aW]S
@
BACDCEF
G HI
!
) *+
-,.
-01/
2
" # $ %&('
b SXcdSV_ eSfY\[W]S^R\_PWVS
図 5.4: IEEE1394 からのデータ入力に従った送信方式
; <<>=
?A@BC@>DE; FG
.
0 /1
234
56
78
19:
PRQTSVUXWZY[U[Q\P^]_U[Q
H>JIKLMKNO><; FG
$ %&
(')
-
+(*,
!#"
` QVabQT] cQdWZYU[Q\PZ]DUTQ
図 5.5: バッファリングによるバースト転送抑制方式
2. パケットロス発生につながるジッタ閾値の設定
3. パケットフロー観測に基づくレート制御
45
5.6. 受信ノード上での輻輳検知とレート制御
5.6.1
利用可能帯域幅の算出
パケットペア理論を用いた bprobe の手法を応用した帯域幅の計算を行う．RTP と RTCP
を用いることで，送信ノード，受信ノード間の伝送遅延時間の計算，連続するパケット間
の相対時間 (ジッタ) が計測できる．また，ストリーミングの特徴であるパケット数の多さ
を利用することで bprobe に近い計測アプローチが可能である．また，帯域幅を増加させ
る時間粒度を短くすることで，利用可能帯域幅の計算，および次のステップであるパケッ
トロス発生につながるジッタ閾値の設定を短時間で終了できる．
帯域幅を増加させる時間粒度を長くとるスロースタートの手法は，パケットロスやタイ
ムアウトをメトリックとした利用可能帯域幅の計算には適しているが，フロー計測手法で
はジッタなど，時間粒度の細かな情報をメトリックとした場合には適していない．また，
ボトルネックリンクの利用可能な帯域幅を超過した場合，ボトルネックリンクのネット
ワークインターフェース長を超過するまでの時間を越えた瞬間にパケットロスが発生する
ため，TCP などにおける他のトラフィックとの公平性を考えない場合はファストスター
トが適している．
5.6.2
パケットロス発生につながるジッタ閾値の設定
受信ノード単体では全くパケットロスが発生しないネットワーク上では，ボトルネック
リンクの帯域幅を予測することが困難である．従って，セッション開始時からパケットロ
スが発生した後，パケットロス発生を予測するためのジッタ閾値を設定する．また，パ
ケットロスが発生しない際のジッタ情報を観測し続け，閾値設定の補助を行う．
セッション開始時より，音声配送に用いる Base Layer のパケットに関して，パケットフ
ロー観測を行う．RTP のシーケンス番号を参照し，パケットロス情報を確認する．パケッ
トロスをトリガーとして，現状の最上位 Enhanced Layer に結び付けられた Group Address
に対して Leave 要求を発行し，利用可能帯域幅計算での帯域幅増加を停止させる．
また，閾値の信頼性向上のためサンプル数を増加させる必要がある．そのため，Leave
要求による利用可能帯域幅に対する過剰フローの停止が完了するまでの時間において，パ
ケットロス発生とジッタの相関から，パケットロス発生を予測するためのジッタに閾値を
設定する．
5.6.3
パケットフロー観測に基づく輻輳予測とレート制御
階層数を減少させる場合には，予め設定したジッタの閾値を超えるジッタを観測した場
合，最上位階層と結び付けられた Group Address に対して Leave 要求を発行する．また，
パケットロスが発生した場合は IEEE1394 へ出力するデータにおいて，データ欠損のある
映像フレームをスキップする．
階層数を増加させる場合には，継続的にパケットフロー観測を行いパケットペア理論を
応用した利用可能帯域幅の算出を行う．ボトルネックリンクの利用帯域幅は常に変動して
いるため，変化を観測する毎にレート制御を繰り替えした場合，クエリアに対する負荷，
46
第 5 章パケットフロー観測を用いた RLM の提案と DVTS への応用
マルチキャストルーティングに対する負荷が必要以上に増加する．従って，階層数減少に
対しては再生品質の低下を避けるため，迅速な対応が必要となるが、階層数増加に対して
は長期的観測に基づいた制御が必要となる．設定されたジッタ閾値の超過をトリガーに，
現状の最上位 Enhanced Layer に結び付けられた Group Address に対して Leave 要求の発
行，IEEE1394 へ出力するデータの調整を行う．
図 5.6 にこれまで説明した受信ノード上でのレート制御手法をまとめる．
!
"
#
&'(
)
%
$
図 5.6: レート制御の遷移概要
A において，パケットロスを観測した後，第 3 階層と結び付けられた Group Address に
対して Leave 要求を発行する．A，B 間では，Leave Delay によって第 4 階層のフローが
収束するまでの時間を示している．Leave Delay 中はボトルネックリンクに対して過剰な
フローが発生している状態なため，継続的にパケットロスとジッタの相関を計測する．
E では A，B 間において設定されたジッタ閾値を超えるジッタを観測した場合を示し，
同時に最上位の第 3 階層に対して Leave 要求を発行している．E，F 間は E において発行
された Leave 要求に対する Leave Delay を示している．また，セッションの開始時より継
続して伝送遅延時間，ジッタ，データグラムサイズを参照し，パケットペア理論を応用し
た現状利用可能な帯域幅を算出し続ける．C では，伝送遅延時間の減少を検知しパケット
ペア理論に基づくボトルネックリンクの帯域算出を行う．ボトルネックリンクの帯域が上
位階層を受信するのに十分であると判断された場合，上位階層と結び付けられた Group
Address に対して Join 要求を発行する．C，D 間では，Join 要求を発行後，マルチキャ
47
5.7. 本章のまとめ
スト経路制御によって経路が決定し，データフローが受信ノードまで到達する時間 (Join
Delay) を示している．
5.7
本章のまとめ
本章では，LM の利用環境として大規模同報型ストリーミング配信環境を想定し，その
規模性に適したレート制御手法が RLM であることを示した．また，RLM の問題点とし
て Estimate Delay，メディア品質の低下に着目し，解決手法としてパケット観測手法を用
いた RLM のモデルを提案した．
また，提案手法の評価を行うシステムとして Layered DVTS の設計を行った．その際，
本手法の評価に適したストリーミングシステムについて論じ，DVTS の特徴を生かした
DVTS の拡張機能をべ，各機能についての設計を行った．
次章では，本章で行った設計に基づいた実装について述べる．
48
第 6 章 Layered DVTS の実装
本章では，第 5 章の Layered DVTS の設計に基づくシステム実装について述べる．Layered DVTS は実装において，送信ノード側プログラムである ldvsend，受信ノード側プロ
グラムである ldvrecv に分類できる．
6.1
ldvsend の実装
図 6.1 に ldvsend の実装概要図としてフローチャートを示す．ldvsend では以下に示す順
序で一連の処理が行われる．
1. 音声階層，映像階層群，RTCP の送信に必要なソケットのオープン
2. IEEE1394 デバイスのオープン
3. IEEE1394 から DV データの読み込み
4. 読み込んだ DV データの DIF Block 分割
5. 音声データと映像データの分離
6. 映像データの階層化
7. 映像データの平滑化送信および音声データの定間隔送信
8. RTCP SR による送信ノード情報の送信
「3」に戻る
6.1.1
DV データ階層化の実装
5.3.2 項で述べたように，DV フォーマットでは全てのフレーム，DIF Block は同一デー
タサイズとなる．そのため，1 フレーム分のデータサイズを読み込み DIF Block に分割し
た後，DIF Block ID を参照することで DV データの階層化ができる．図 6.2 に DV データ
階層化手法を示す．
1 フレーム分のデータを IEEE1394 デバイスドライバから読み込んだ後，DIF Block ID
を参照し，AUDIO DIF Block とその他の DIF Block を識別する．フレームを読み込む毎に，
読み込んだフレーム数を記憶し，利用する階層数で除余することで対象となる Enhanced
Layer の Group Address と結び付けられたソケットバッファを識別子しコピーする．
49
6.1. LDVSEND の実装
8
%$4'+B%'!(C
M
; +2:<# =$=$=8?>@A
1'+
%$
>
A
# +H N
!
" $# , !
-'./0
2
N
; $# -
-'/0BKL1?H2
;IEJ
";IE2J
O
";IE2J
2"24365(7 2"43.897 2243:7
%*) +
E 2) %$$D %$: Q
&%'!(
P %$2:
P %$:
P %$:
P %$:
2&%'!?F3G5(7 2&%'!(43.897 2&%'!(43:7
$D ,E %'!(
図 6.1: 送信ノード側実装概要図
6.1.2
音声階層データ定間隔送信の実装
IEEE1394 の転送方式にはアイソクロナス転送，アシンクロナス転送の 2 種類が存在す
る．前者は映像・音声を初めとした実時間性が高いデータ転送に用いられ，後者はそれ以
外のデータ転送に用いられる．IEEE1394 インターフェースを用いた DV データの転送で
は，アイソクロナス転送が用いられるが，OS(Operating System) によってデバイスドラ
イバの実装，アクセス方法は以下の 2 種類に大別される．
• IEEE1394 アイソクロナス転送で受け渡されるデータを直接ユーザランドへ渡す
• IEEE1394 アイソクロナス転送で受け渡されるデータをバッファリングし，DV フ
レームを構成するデータ量単位でユーザランドへ渡す
FreeBSD，NetBSD，Linux の raw1394 デバイスドライバは前者の方式を用い，Linux の
dv1394 デバイスドライバは後者の方式を用いている．nanosleep() を用いることで，dv1394
デバイスドライバを用いた場合も定間隔のパケット送信が可能であるが，この手法は単
一ソケットを用い，そのプロセス優先度を上昇させた時に効果を発揮する [31]．Layered
DVTS では最大で 32 個のソケットを利用する可能性があり，nanosleep() を用いた場合，
Enhanced Layer に用いるソケットへの処理に悪影響が出るため現実的ではない．また，前
者の方式を用いる場合，5.3.2 項で述べた DIF Sequence，DIF Block Number を用いるこ
50
第 6 章 Layered DVTS の実装
¶
³
/* DIF Block 読み込み処理 */
int layer_id
/* 映像バッファの ID */
int layer_num
/* 階層数 */
u_int32_t framecount;
/* 1 フレーム読む毎に増加 */
layer = framecount % layer_num;
/* DIF ブロックの分別，バッファへのコピー */
u_int32_t *difblock
/* DIF Block Data へのポインタ */
int dbn, dseq, did;
dbn = (ntohl(difblock[0]) >> 8) & 0xff; /* DIF Block Number */
dseq = (ntohl(difblock[0]) >> 20) & 0xf; /* DIF Sequence */
did = (ntohl(difblock[0]) >> 29) & 0x7; /* DIF Block ID */
if(did == AUDIO_DIF_BLOCK_ID){
/* 音声ソケットバッファへコピー */
proc_audio_dif(difblock);
}
else{
/* 該当する映像階層のソケットバッファへコピー */
proc_audio_dif(difblock, layer);
}
µ
´
図 6.2: DV データの階層化
とでフレーム単位でのデータ取得が実現する．従って、Layered DVTS では，IEEE1394 ア
イソクロナス転送をユーザランドへ直接渡すデバイスドライバである FreeBSD を用いる．
6.2
ldvrecv の実装
ldvrecv はパケット受信プロセス，映像出力プロセス，輻輳検知・レート制御プロセスに
よって構成される．図 6.3 に受信ノード側の実装概要としてフローチャートを示す．ldvrecv
では以下に示す順序で一連の処理が行われる．
1. 音声階層，映像階層群，RTCP の受信に必要なソケットのオープン
51
6.2. LDVRECV の実装
2. IEEE1394 デバイスのオープン
3. パケット受信プロセスによる各ソケットからの DV データ受信
4. 音声階層パケットフロー観測によるジッタ計測
輻輳検知・レート制御プロセスへ観測データ送信
5. 音声階層，映像階層群ソケットのパケットロス数観測
輻輳検知・レート制御プロセスへ観測データ送信
6. DV データの DIF Sequence，Time Code を利用したバッファコピー
パケット受信プロセスは「3」に戻る
7. 映像出力プロセスによるパケット受信プロセスのバッファ書き込み状況チェック
映像出力プロセスによる IEEE1394 デバイスへの DV データ書き込み
映像出力プロセスは「7」に戻る
8. 輻輳検知・レート制御プロセスによる RTCP パケットの受信
送信ノード・受信ノード間の伝送遅延時間算出
9. パケット受信プロセスよりジッタ，パケットロス数の受信
10. 伝送遅延時間，ジッタ，パケットロス数に基づくレート制御
11. パケットロス数に基づく映像出力プロセスへの出力量調整輻輳検知・レート制御プ
ロセスは「8」に戻る
6.2.1
階層化 DV データ再構成の実装
5.5 節において，DV の階層化では音声データを Base Layer とし，映像フレームを任意
の階層数で Enhanced Layer とすると述べた．DV フォーマットでは，DIF Block の種類
として「HEADER」，
「SUBCODE」，
「VAUX」，
「AUDIO」，
「VIDEO」の 5 種類が定義さ
れている．DIF Block の種類は DIF Block の先頭 3Byte に確保されている DIF Block ID
を参照することで判別することができる．各 DIF Block は，3 バイト長の ID ヘッダを含
む ID ヘッダによって DIF Block の種類とデータの位置を示す．
DV フォーマットでは SUBCODE 中のパックと呼ばれる 5Byte のデータ集合にタイム
コードが格納されている．タイムコードはデータがテープに記録された際に記載され、
「時間:分:秒:フレーム番号」の順に表される．また，NTSC 方式の場合，Drop Frame Flag
によって，30fps と 29.97fps の場合を識別する．タイムコードと，5.3.2 項で述べた DIF
Sequence，DIF Block Number を用いることで，異なるソケットから受信する階層化され
た DV データの再構成をが可能になる．
図 6.4 に階層化された DV データの再構成手法を示す．Base Layer である音声データを
受信するソケットからのパケットには SUBCODE が格納されない．しかし，ソケットに
52
第 6 章 Layered DVTS の実装
6##57
$8))
= @+&,! A
aCbPcCdfe*gihjNkKljTm
MVX
iWmY
x
$8,)7$%#&'()1
t
9 7;: <8<8<%(=>,?
( D #E - #5)F#5D
@+o -/p $%#&'()
@%&,! A
-/. &'nG! ))
>
-/. &'s6#11
G#5! H6A
>
u
34"5! #$+#&'(,)
-/. &'
0+12
u
= @+&,! A
?
p D ,q - #5)#rD
= @%&,! A
u
= @%&,! A
! "#$%#&'()( ! "#$%#&'()* ! "#$+#&',)
v
IP
KJMLON5QSRUTMVXWZY
- #57q
- #57q
- #57q
w
BC! )
: <8<8<%(=>,?
[]\_^P`]TMVXWZY
図 6.3: 受信ノード側実装概要図
よってフレームが分割されないため，タイムコードによるフレームの調査が必要ない．そ
のため，RTP パケットに格納された DIF ブロックを個々に取得し，DIF Sequence と DIF
Block Number を調査することで，格納すべきバッファのメモリ番号が確定する．Enhanced
Layer である映像データは，ソケットによってフレームが分割される可能性があるため，
タイムコードによってフレーム番号を調査する必要がある．フレーム番号を調査すること
で，格納すべき DV フレームバッファを決定できる．格納すべきバッファのメモリ番号は
音声と同様の手法によって識別される．
6.2.2
伝送遅延時間算出の実装
伝送遅延時間は RTCP SR の NTP Timestamp を用いて算出する．送信ノード，受信
ノードはそれぞれ NTP(Network Time Protocol)[32] を用いて絶対時間同期が行われて
いることを前提とし，RTCP SR の N T P T imestamp フィールドに格納される．しかし，
NTP は複数の同一 Stratum に所属する NTP サーバを参照し，最も確からしい時間を配
布しているサーバを選出する方法の採用した場合，約 10 ミリ秒の同期誤差とされてい
る [33]．NTP Timestamp には送信ノード上で RTCP SR パケットを送信する直前の処理
で，通常は gettimeof day() によって取得した時刻を格納する．そのため，伝送遅延時間
はこの誤差を考慮して利用する必要があるが，通常のインターネット通信において 100 秒
53
6.2. LDVRECV の実装
"!#$%&'
5.6.7 021 01
34&3 01
() "!#$%&*'&
5.6.7 021 01
( "!>$%*'
3&3
3&3 021
5.6.7 021 01
3&3 021
98;:$%
+,<$:$%
+,.- +,.-
=$:$%
=- =-@?
=- C
=- A
=- B
/
=- =-@?
=- C
=- A
=- B
=D- =D-@?
=- C
=D- A
=D- B
/
=D- =D-@?
=- C
=D- A
=D- B
"E
F?G
=- =-@?
=- C
=- A
=- B
/
=- =-@?
=- C
=- A
=- B
3&43
図 6.4: DV フレームの再構成手法
を超える伝送遅延時間は特別なネットワークを構築しない限りほとんどない．そのため，
gettimeof day() によって取得される tv.sec の変数は過剰なバッファ長であるため，Layered
DVTS では getnannotime() を用いる．受信ノード上では，RTCP SR パケット受信直後
の処理で getnanotime() によって取得した時刻と，RTCP SR パケット内に格納されてい
る NTP Timestamp との差から送信ノード，受信ノード間の伝送遅延時間を算出する．
6.2.3
ジッタ値計測の実装
ジッタ値計測では，送信ノードが一定間隔でパケットを送信していることを前提とし
て，4.4 節で述べたパケット到達間隔の揺らぎを計測する．ldvsend では音声データを転
送する Base Layer のみを一定間隔で送信しているため，Base Layer を受信するソケット
に対して recvf rom() を発行した際の時間を計測し，ジッタ値を算出する．また、第 4 章
で述べた通り，ジッタ値は絶対値が大きい程輻輳状態に近いことを示している．従って，
ジッタ値は可能な限り正確に計測する必要がある．そのため，ジッタ値計測には CPU ク
ロックカウンタを用いて実装した．
しかし，通常のマルチタスク OS の処理ではパケットがネットワークインターフェース
キューに格納されてから，ユーザーランド上で recvf rom() が呼び出され，ジッタ値を取
得するまでの時間に大きな遅延が発生する場合がある．例えばカーネル割り込み処理が行
われた場合，その処理が終了するまでユーザーランドでのパケット受信処理ができない．
この問題に対して，Layered DVTS では Device Polling を用いて，OS による定期的なデ
バイスチェックを活用した．
54
第 6 章 Layered DVTS の実装
6.2.4
パケットフロー観測手法を用いたレート制御
Layered DVTS ではレートコントロールにおいて階層減少アルゴリズムにジッタ値を用
い，階層増加アルゴリズムにパケットペア理論によるボトルネックリンク帯域算出手法を
用いる．階層減少アルゴリズムでは，パケットロスが発生した際それまでのジッタ値の分
散を格納し，パケットロスに関わるジッタの値を最上位階層に対して Leave 要求を発行す
るためのジッタ閾値として設定する．また，第 4 章での予備実験の結果より，パケットロ
ス発せに起因せず，1 秒以上前のジッタ値が最大値だった場合は，その値を反映しない．
階層増加アルゴリズムでは，伝送遅延時間の相対値とパケットロス率を参照し輻輳の収
束を予測する．DVTS では，RTP パケットサイズが一定なため，送信される階層数によっ
て，ldvrecv は単一の Enhanced Layer に必要な帯域幅を計算できる．そのため，パケット
ロス率から粒度の荒いボトルネックリンクの帯域幅を計測可能である．また，パケットロ
スが発生しない場合の伝送遅延時間とパケットロス発生時の伝送遅延時間から，ボトル
ネックリンクを通過する際に発生する遅延時間を算出できる．この手法は伝送遅延時間に
対する揺らぎの相対値を用いているため，送信ノードと受信ノード間では NTP を用いて
絶対時間同期後に刻まれる時間がほぼ等しいことを期待している．そのため，NTP の時
間同期性能に依存しない伝送遅延時間の利用ができる．
55
第7章
評価と考察
本章では，パケットフロー観測手法を用いた RLM ストリーミングを 1.5 節で述べた本
研究の目的と 3.6 節で述べた既存 RLM の問題点から，以下に示す項目で評価する．
• 定性的評価項目: Layered DVTS の機能
– ストリーミングアプリケーションの機能
– RLM における輻輳検知・制御手法
• 定量的評価項目: Layered DVTS の性能
– Join Experiment 方式と比較した Estimate Delay
– Join Experiment 方式と比較した階層増加アルゴリズム
7.1
定性評価
Layered DVTS が実現したストリーミングアプリケーションとしての機能および RLM
における輻輳検知・レート制御機能を既存手法と比較評価する．ストリーミングアプリ
ケーションの機能に対する比較対象として，既存のマルチキャスト配信可能なストリーミ
ングアプリケーションである DVTS を挙げる．また，RLM の輻輳検知・制御手法に対す
る比較対象として Join Experiment 方式を挙げる．
7.1.1
ストリーミングアプリケーションの機能評価
1.5 節において，本研究は送信者と中継網の要求である規模性と受信者の要求である多
様なメディア再生環境への両立を目的とした．DVTS によるユニキャスト配信，マルチ
キャスト配信，Layered DVTS によるマルチキャスト配信が持つレート制御機能と規模性
の比較を表 7.1 に示す．
DVTS にはメディア品質の変化によるレート制御において，フレームレートを基調とし
たレート制御機能がある．ユニキャスト通信によるストリーミング配信では，個々の受信
ノードに適応したレート制御をサポートしている．また，ECN，TCP-Friendly，RTCP
を用いた輻輳検知・制御機能を持ち，送信ノードが主体となったレート制御を行う．その
ため，輻輳検知精度と輻輳収束速度に優れている．しかし，ユニキャストによる通信のた
56
第 7 章評価と考察
表 7.1: 複数の受信ノードに対するストリーミング配信機能の比較
手法
レート制御
規模性輻輳検知・制御精度
DVTS(ユニキャスト)
DVTS(IP マルチキャスト)
Layered DVTS
受信ノード毎
単一レートのみ
受信ノード毎
×
○
○
○
できない
△
め一台の送信ノードが処理可能な受信ノード数は送信ノードの計算機資源，ネットワーク
資源に依存し，規模性に欠ける．
IP マルチキャストを用いたストリーミング配信を行った場合，全ての受信ノードに対
して同一レートでの配信のみサポートされているが，輻輳検知・制御機構をサポートし
ていない [34]．また，送信ノードとに必要となる資源が受信ノード数に依存せず一定であ
り，ユニキャストと比較して中継ノードのネットワーク資源を効率よく利用するため規模
性に優れている．
Layered DVTS はフレームレートを基調とした階層化し，各階層に異なる Group Address
を結びつけ IP マルチキャストを用いて配信する．そのため，各受信ノードの環境に応じた
レート制御ができる．また，RTCP とフロー観測手法に基づく受信者単体での輻輳検知・
レート制御機能を持つ．送信ノードと中継ノードに必要となる資源は通常のマルチキャス
トによる DVTS と同様に，受信ノード数に依存せず一定のため規模性に優れている．
以上より，Layered DVTS は IP マルチキャストを用いた規模性の高い同報通信と同時
に，受信ノード毎のレート制御，すなわち品質調整機能を満たしている．
7.1.2
RLM おける輻輳検知・制御機能の評価
Join Experiment 方式と Layered DVTS における RLM の輻輳検知・制御機能比較を表
7.2 に示す．
表 7.2: RLM における輻輳検知・制御機能の比較
手法
階層増加手法
階層減少手法
(輻輳収束検知手法)
(輻輳検知・制御手法)
Join Experiment 方式
Layered DVTS
Join Timer
伝送遅延時間計測
パケットロス検知
ジッタ計測 (パケットロス)
既存 RLM の輻輳検知・制御アルゴリズムである Join Experiment 方式ではパケットロ
スを基準とした階層減少アルゴリズムがある．階層増加アルゴリズムでは，ネットワーク
状況の検知基準が無く，Join Timer によるタイマー処理のみが行われている．そのため，
輻輳収束を検知するための根拠となるパラメータが存在しない．また，パケットロスの検
知をトリガーとして即座に階層減少アルゴリズムを動作させる．そのため，Join Timer の
57
7.2. JOIN EXPERIMENT 方式との ESTIMATE DELAY 比較
値が小さいストリーミング受信の初期段階は階層変更を頻繁に繰り返すことでメディア再
生品質を著しく低減させる．
本手法では，第 4 章で示した，伝送遅延時間の統計的な計測による輻輳収束検知を用い
ることで，ネットワーク状況に基づいた階層増加アルゴリズムを新規に追加した．また，
ジッタの統計的な計測による輻輳予測を用いることで，パケットロス検知よりも早期に輻
輳を検知し，動作する階層減少アルゴリズムを新規に追加した．
7.2
Join Experiment 方式との Estimate Delay 比較
RLM の欠点である Estimate Delay が削減できたかを評価するため，Join Experiment
方式と比較した Estimate Delay の比較を行う．もう一つの欠点である Leave Delay がマ
ルチキャスト経路制御プロトコルとその設定に依存するため，Estimate Delay は RLM の
輻輳収束速度に関して最も重要な時間である．
Join Experiment 方式がパケットロスを基準とした輻輳検知を行うのに対し，本手法で
はパケットフロー観測手法を用いたジッタ値分散の変動を基準とした輻輳予測を行った．
第 4 章で示したように送信ノードから受信ノードへの伝送遅延時間によってパケットフ
ロー観測結果の傾向が異なるため，複数の遅延時間を考慮した計測を行った．表 7.3 に，
本手法によってパケットロスを基準とする手法から短縮した時間を示す．本手法は伝送遅
延時間によって結果は異なるが，Estimate Delay を低減しているのが分かる．
表 7.3: Estimate Delay の低減
伝送遅延時間本手法による低減値
10 ミリ秒
30 ミリ秒
60 ミリ秒
90 ミリ秒
140
125
128
138
(ミリ秒)
(ミリ秒)
(ミリ秒)
(ミリ秒)
式 4.15 に利用した変数を引用し，Estimate Delay の差分を EstimateDelayDif f erence，
ネットワークインターフェースキュー長を超過したデータサイズを DroppedLength，DroppedP ackets
を欠損したパケット数とした場合，ボトルネックリンクにおける Estimate Delay の短縮
がパケットロス量に与える影響を式 7.1 と式 7.2 で表すことができる．
m − λ × EstimateDelayDif f erence × P = DroppedLength
(7.1)
DroppedLength ÷ P = DroppedP ackets
(7.2)
DV フォーマットは，個々の映像フレームで一つの画像を構成する．受信ノードが同一
階層数に対して参加している場合パケットロス率と再生品質の劣化の関係が平等である．
そのため，MPEG をはじめとしたフレーム間圧縮フォーマットと異なり，パケットロス
58
第 7 章評価と考察
率が直接メディア再生品質に影響する．従って，本手法の有効性はボトルネックリンクの
キュー長によって異なるが，Estimate Delay の時間短縮率からパケットロス率を低減し，
メディア再生品質を向上させた．
59
第8章
結論
本研究では，パケットフロー観測手法を用いた受信者駆動型階層化マルチキャスト (RLM)
ストリーミングを提案し，大規模かつ多様な受信ノード環境に適応した同報型ストリーミ
ング配信機構を実現した．
大規模同報型ストリーミング配信を送信者・中継網・受信者に大別することで，各要素
の要求を比較し分析した．各要素の要求事項とストリーミングの要素技術の比較より，送
信者，中継網の要求に対しては IP マルチキャストが高い効果が期待されるが，受信者の
要求を同時に満たすことが困難であることを示した．
IP マルチキャストを用いた同報型ストリーミング配信上で，受信者の要求である受信
環境の多様性への対応と再生品質の保証を満たす手法として，既存技術を参照し比較検
討を行った．各要素の要求を実現する技術を比較検討によって，中継網による輻輳制御，
レート制御は，全ての中継ノードがその機能持つ必要があるため規模性にかける．また，
中継ノードにパケット転送以外の処理を担当させることはインターネットの構造上現実的
でないことを示した．また，大規模同報型ストリーミング配信において，送信者・受信者
間の連携による輻輳制御，レート制御は送信者の端末資源を過剰消費するため，規模性と
相反することを示した．
送信者，中継網の要求である効率の良いストリーミング資源活用と，受信者の要求であ
る受信環境に適応したストリーミング配信・再生品質の保証を両立させる手法として，本
研究では LM(Layered Multicast) に着目した．しかし，既存の LM 技術既存の LM 研究成
果を RLM・SLM・NLM に分類し，大規模環境での動作要件を分析した．
しかし，これまでの Layered Multicast はインターネット上のサービスとしてそのまま
活用することができない．そこで，既存の Layered Multicast の手法を RLM・SLM・NLM
に分類し，大規模同報型ストリーミング配信環境で必要となる動作要件を分析した．この
分析から，本研究では規模性に着目し RLM のモデルを採用した．解決すべき RLM の問
題点となっている Estimate Delay の短縮と再生品質の向上を目標とした．
RLM の Estimate Delay 短縮のため，受信ノード単体で取得可能なネットワーク状況把
握に活用可能なデータを輻輳メカニズムのモデル化より分析した．輻輳メカニズムの分析
より，パケットフロー観測手法によるジッタ・伝送遅延時間・パケットロスに着目し，受
信者単体での輻輳検知に必要な予備実験を行った．その結果からパケットフロー観測手法
を RLM に適用し，Estimate Delay を短縮する手法を提案し，アプリケーション例として
Layered DVTS の設計・実装を行った．
本研究成果の評価として，Layered DVTS が実現した機能の評価と既存 RLM の輻輳制
御手法である Join Experiment 方式の Estimate Delay を比較した．Layered DVTS のスト
リーミングアプリケーションの機能より，多様な受信環境に対応した IP マルチキャスト
60
第 8 章結論
ストリーミングを実現した．Join Experiment 方式と比較して Estimate Delay を約 130 ミ
リ秒短縮した．また，パケットフロー観測手法によるパケットロス以外のパラメータを活
用することで，Join Experiment 方式と比較して精度の高いな輻輳検知を実現した．
本研究により，大規模化・高品質化・受信環境の多様化が進む同報型ストリーミング配
信において，送信者，受信者の要求を満たし，中継網に対する負荷の少ない配信の基礎が
実現された．
61
第9章
今後の課題
本研究の今後の課題として，パケットフロー観測手法を用いた輻輳予測精度の向上，本
手法を用いた実用アプリケーションの実装，メディア再生品質の信頼性向上，および運用
モデルの構築が挙げられる．
パケットフロー観測手法を用いた輻輳予測精度として，パケットロス発生前の最大ジッ
タ値ではなく，ジッタ値の継続観測より統計的な視点からはずれ値を検知するアルゴリズ
ムなどを検討することができる．
実用アプリケーションとして，低帯域で高品質メディアを構成するフレーム間圧縮フォー
マットへのフィードバックがある．特に複数の動画像解像度が定義されている MPEG-2，
H.264 AVC，JPEG 2000 などを用いることで，画像解像度出力性能が異なる受信ノード
に適応した同報型ストリーミング配信ができる．また，複数の音声出力を持つ音声コー
デックを利用することで，音声出力機器数の異なる受信ノードに適応した同報型ストリー
ミング配信ができる．
メディア再生品質の信頼性向上技術として，信頼性マルチキャストとの連携が考えられ
る．特に第 3 章で述べた FEC 方式は，フレーム間圧縮フォーマットを用いる際，高い効
果が期待できる．また，本手法で用いた受信ノード単体で取得可能な輻輳検知要素以外の
手法に着目し，より高い精度での輻輳検知を行うことが可能である．
既存研究では LM の輻輳制御，レート制御に関しては議論がされてきたが，運用モデル
に関する議論はされてこなかった．特に LM のセッション広告手法，受信ノードの資源に
応じた受信要求手法など，LM をインターネット上にサービス展開に必要となる技術の開
発が今後必要である．また，広域なマルチキャストネットワーク基盤を構築し，LM をは
じめとした同報型通信の基盤構築が必要である．
62
謝辞
本論を進めるにあたり，主査である慶應義塾大学環境情報学部教授の村井純博士に感謝
致します．また副査である慶應義塾大学環境情報学部助教授の中村修博士と東京大学大学
院情報理工学系研究科教授の江崎浩博士に感謝致します．
また常に御指導を頂きました，政策・メディア研究科助手の杉浦一徳博士，環境情報学
部専任講師の重近範行博士に感謝致します．
身近な先輩として御助言頂きました慶應義塾政策・メディア研究科博士課程の海崎良
氏，石原知洋，片岡光太郎氏，SFC 研究所上席所員の小川浩司氏に感謝致します．
面倒で細やかな作業を手伝っていただきました慶應義塾政策・メディア研究科修士課程
の松園和久氏と慶應義塾大学環境情報学部の遠峰隆史氏，数学が苦手な私に手引きしてく
れた慶應義塾大学環境情報学部の金井瑛氏，卒業論文で忙しい中考えをまとめるために話
をしてくれた慶應義塾大学環境情報学部の大薮勇輝氏に感謝します．
修士論文執筆の中で苦楽を共にした，橋本和樹氏，佐川昭宏氏，仲山昌宏氏に感謝致し
ます．弱気になりながらも共に頑張った廣瀬峻氏，山本聡氏，白畑真氏，熊木美代子氏に
感謝致します．ここぞと言うところでファイルを買ってきてくれた三島和宏氏，素晴らし
いエスプレッソメーカーと共に日々の生活を支えてくれた工藤紀篤氏，公私において苦楽
を共にし，恐らく一番一緒に執筆していたであろう久松剛氏に感謝致します．
そして最後にモービル広域ネットワーク (MAUI) プロジェクト及び徳田・村井・中村・
楠本・高汐・湧川研究室の諸氏，特に STREAM 研究グループの皆様に感謝致します．
以上を持って謝辞といたします．
63
参考文献
[1] Akmichi Ogawa. DVTS(Digital Video Transport Sysytem). http: // www. sfc. wide. ad.
jp/ DVTS/ .
[2] J. Postel. RFC768 User Datagram Protocol. http://www.ietf.org/rfc/rfc0768.txt, pages
1–3, August 1980.
[3] Audio-Video Transport Working Group. RFC1889 RTP: A Transport Protocol for RealTime Applications. http: // www. ietf. org/ rfc/ rfc1889. txt , pages 1–75, Jan 1996.
[4] K.K.Ramakrishnan,S.Floyd,D.Black. The Addition of Explicit Congestion Notification
(ECN) to IP, September 2001. RFC 3168.
[5] MPEG-2 Generic coding of moving pictures and associated audio information. http://
www.chiariglione.org/mpeg/standards/mpeg-2/mpeg-2.htm.
[6] David Taubman. High performance scalable image compression with ebcot. In IEEE
Transactions on Image Processing Vol.9 No.7, pages 1158–1170, 2000.
[7] David Taubman, Erik Ordentlich, Marcelo Weinberger, Gadiel Seroussi, and Ikuro Ueno Fumitaka Ono. Embedded block coding in jpeg2000. In IEEE International Conference on
Image Processing (ICIP), pages 33–36, 2000.
[8] S.Floyd and K.Fall. Promoting the use of end-to-end congestion controlin the internet.
IEEE/ACM Transactions on Networking, 1998.
[9] Kitae Nahm and Qing Li C.-C. Jay Kuo. A practical tcp-friendly layered video multicast
over active queue management. IEEE INFOCOM, Hong Kong, 2004.
[10] 山口一郎本間健一甲藤二郎. TCP 親和性を持つ受信者駆動型階層化マルチキャストとレー
ト制御に関する一検討. 電子情報通信学会情報ネットワーク研究会, 2002.
[11] 村本衛一米田孝弘鈴木史章鈴木良宏中村敦司. 送信者起動マルチキャストにおける輻輳制
御方法の提案. インターネットコンファレンス, 2003.
[12] 市川俊一淺谷耕一富永英義. 誤り訂正符号を用いた損失耐性のある階層化マルチキャスト
レート制御. 電子情報通信学会論文誌 VOL.J86-B No.2, 2003.
[13] 佐々木克博中内清秀森川博之青山友紀. マルチキャストフローに適したパケットドロップア
ルゴリズムの設計. 情処学マルチメディア, 分散, 協調とモバイルシンポジウム (DICOMO’99),
June 1999.
[14] Dan Bricklin. Why We Don’t Need QOS. http://www.bricklin.com/qos.htm,asof2005/
12/19.
64
第 9 章今後の課題
[15] 中内清秀森川博之青山友紀. マルチキャストストリーミングメディアにおけるレート制御
機構. 情処学マルチメディア, 分散, 協調とモバイルシンポジウム (DICOMO’00), June 2000.
[16] 三島和宏. 伝送特性に応じた適応型映像・音声配信機構の設計と構築. 慶應義塾大学環境情
報学部卒業論文, 2003.
[17] 松園和久. パケットフロー特性に着目した映像音声配信モデルの研究. 慶應義塾大学環境情報
学部卒業論文, 2004.
[18] S.E. Deering. RFC1112 Host extensions for IP multicasting(defines IGMP Version 1).
http: // www. ietf. org/ rfc/ rfc1112. txt , August 1989.
[19] W. Fenner. RFC2236 Internet Group Management Protocol, Version 2. http: // www.
ietf. org/ rfc/ rfc2236. txt , November 1997.
[20] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. RFC3376 Internet Group
Management Protocol, Version 3. http: // www. ietf. org/ rfc/ rfc3376. txt , October
2002.
[21] S. Deering, W. Fenner, B. Haberman. RFC2710 Multicast Listener Discovery (MLD) for
IPv6. http: // www. ietf. org/ rfc/ rfc2710. txt , October 1999.
[22] R. Vida, Ed., L. Costa, Ed. Multicast Listener Discovery Version 2 (MLDv2) for IPv6.
http: // www. ietf. org/ rfc/ rfc3810. txt , June 2004.
[23] A.Ogawa K.Sugiura O.Nakamura J.Murai. Implementing tcp-friendliness in digital video
over ip. 情報処理学会論文誌第 43 巻第 2 号, February 2002.
[24] S. Keshav. A control-theoretic approach to flow control. In ACM SIGCOMM, pages 3–15,
1991.
[25] M. Carter, R. Crovella. Bottleneck link speed in packet-switched networks technical report.
Computer Science Department,Boston University, 1996.
[26] 笠原正治. インターネットトラヒックモデリング-通信トラヒック理論からインターネット設
計理論へ. 電子情報通信学会技術研究報告, 2002.
[27] 村田正幸高垣景一, 大崎博之. 流体近似法および待ち行列理論を組み合わせた TCP の
フィードバック型輻輳制御機構のモデル化. 電子情報通信学会交換システム研究会, 2001.
[28] Stephen Jacobs Alexandros Eleftheriadis. Streaming video using dynamic rate shaping and
TCP flow control. Journal of Visual Communication and Image Representation, 9(3):211–
222, 1998.
[29] S. Jacobs A. Eleftheriadis. Real-time video on the web using dynamic rate shaping.
[30] Akimichi Ogawa. Design and implementation of dv based video transportation with congestion control. 2003.
[31] 入野仁杉浦一徳中村修村井純. パケットフローコントロールによる dv 転送品質向上の
研究. 第 12 回マルチメディア通信と分散処理ワークショップ ; 情報処理学会, 2004.
[32] D.L. Mills. Network Time Protocol (NTP), September 1985. RFC 958.
65
[33] 伊藤大輔山下聡三宅延久外山勝保. インターネット上の高精度な時刻配信サーバの運用. 情
報科学技術フォーラム, Sep 2002.
[34] 菅沢延彦. IP マルチキャストを用いた放送型 VoD 機構の実現. 修士論文, 2002.

Download Report