You are on page 1of 64

インターネット上の高品質な

遠隔コラボレーションに関する
研究

広島市立大学大学院 博士後期課程
情報科学研究科 情報科学専攻
コンピュータ情報科学系

岸田 崇志
HIROSHIMA CITY
UNIVERSITY
2
発表概要
 研究の背景と目的
 次世代ブロードバンドアプリケーションに
おける問題点
 遠隔コラボレーションシステム
多目的音声伝送システム MRAT
MRAT を用いた実践
プロトコル変換ゲートウェイ PTGATE
 研究のまとめ

2006.2.24 HIROSHIMA CITY


UNIVERSITY
3

研究の背景と目的

2006.2.24 HIROSHIMA CITY


UNIVERSITY
4
背景
 インターネットの利用の変化
Web や E-Mail を中心とした利用
アクセスラインの広帯
域化
映像や音声の利用が可能に
 研究基盤インフラの 新たなコミュニケーションの
整備 可能性
 次世代プロトコルの
開発
 双方向アプリケー
ションの開発
より高品質,より多様な
コミュニケーションが可能に
2006.2.24 HIROSHIMA CITY
UNIVERSITY
これからのコミュニケーションに望まれ 5

るもの
 新たな利用方法に対応すること
 新たな利用要求が生まれてきている
※ 現在は会話が中心
 対面のコミュニケーションにより近づくこと
双方向性が高いこと
高品質な映像や音声
映像では, SDTV 品質以上.音声では,電話品質を上回る
もの
パケット損失の影響が少ないこと
双方向性が高く高品質なインターネット上の
コミュニケーションを遠隔コラボレーションと
 
定義
遠隔コラボレーションの実現によりネットワークを意識せず
現実のコミュニケーションと同じことが行える環境へ
2006.2.24 HIROSHIMA CITY
UNIVERSITY
問題点1:
6
次世代インフラストラクチャとアプリケーションとの
ギャップ
遠隔コラボレーションを行える環境が築かれている
JGN II :日本 (20Gbps) 研究機関を中心に利用
vBNS :米国 (10Gbps) 定常的な利用に至っていない
Abilene :米国 (2.4Gbps)
CA*net 4 :カナダ アプリケーションの
(10Gbps)
広帯域,高品質,次世代プロトコル 開発・利用

次世代インフラストラクチャ
の整備

インフラストラクチャの整備と比較して
アプリケーションの開発や利用が進んでいない
2006.2.24 HIROSHIMA CITY
UNIVERSITY
問題点2:
7
RTPの利用と次世代インフラストラクチャとの
ギャップ
 リアルタイム通信を行うプロトコル
RTP(RFC3550)
 多くのアプリケーションに実装
 パケット損失の問題
 同じパケット損失率でも影響が大きく違う
Ex.) パケット損失率 1 % の場合
パケット損失に対する扱いを検討する必要がある
 VIC (700kbps) 従来アプリケーション
 再生バッファの問題
   80pps 1 秒間のパケット損失数 0.8 パケット (5 秒に 4 パケット損失
 RTP では遅延の揺らぎを吸収し,一定の間隔で再生を
 DVTS (30Mbps) 広帯域アプリケーション
行うためのバッファ機構がある
   3000pps 1 秒間のパケット損失数 30 パケット
バッファ機構と低遅延伝送はトレードオフ

低遅延伝送を目指すためには,揺らぎを吸収するだけでなく
バッファ長を見積もる機構を見直す必要がある
2006.2.24 HIROSHIMA CITY
UNIVERSITY
問題点3: 8

ネットワーク仕様やニーズの多様化に因る問題
 ネットワーク仕様の多様化に因る問題
 異なるネットワークプロトコルの混在
マルチキャスト対応ネットワークと非対応ネット
ワーク
IPv4 環境と IPv6 環境
– 今後は IPv6 の普及により,より混在していく
– 広域配送時において問題がより顕著に

 NAT ネットワーク環境に因らず相互通信を可能にする
, Firewall 機器による通信の制限
環境を創り出す必要がある
 
 ニーズの多様化に因る問題
 従来のアプリケーションでは実現不可能な利用要求
新たなニーズに応えるアプリケーションの開発が
必要
2006.2.24 HIROSHIMA CITY
UNIVERSITY
9
研究の目的
 遠隔コラボレーションを実現するために

 多様化するニーズにおいて要求条件をまとめる
こと
要求条件を満たし,次世代インフラストラクチャを
  活用
するブロードバンドアプリケーションの開発を行う
こと
日常的な利用に向けて,多くの遠隔コラボレーショ
  ンの
利活用を進めること

2006.2.24 HIROSHIMA CITY


UNIVERSITY
遠隔コラボレーションの普及へ向け 10


アプリケーションの利用可能性の追求
利用場面の分析とそれを実現するアプリケーションの
開発

リ遠
ケ隔
ーコ 遠隔コラボレーション普及に向けて,
シラ 双方の相乗効果が必要
ョボ
ンレ
のー
開シ
発ョ

を Communication quality

現 Network configuration




利用できる環境の構築
遠隔コラボレーションの利用場面の拡 利用の発展

2006.2.24 HIROSHIMA CITY
UNIVERSITY
11
遠隔コラボレーションシステム
 遠隔コラボレーションシステムの設計と開発
 開発には二つのアプローチを採用

 エンドシステム
エンドシステム
利用場面における要求条件の分析
要求条件を満たす実装
中間システム
中間システム
多様なネットワーク仕様に適応する
インターオペラビリティの向上

 実践

2006.2.24 HIROSHIMA CITY


UNIVERSITY
遠隔コラボレーションの普及へ向け 12


アプリケーションの利用可能性の追求
利用場面の分析とそれを実現するアプリケーションの開

プ遠
リ隔
ケコ 遠隔コラボレーション普及に向けて,
ーラ 双方の相乗効果が必要
シボ
ョレ
ンー
のシ
開ョ
発ン
を Communication quality

現 Network configuration


利用できる環境の構築
遠隔コラボレーション利用場面の拡 利用の発展

2006.2.24 HIROSHIMA CITY
UNIVERSITY
13
遠隔コラボレーションシステム
 遠隔コラボレーションシステムの設計と開発
 開発には二つのアプローチを採用

 エンドシステム
エンドシステム
アプリケーションの要求条件の分析
要求条件を満たす実装
中間システム
中間システム
多様なネットワーク仕様に適応する
インターオペラビリティの向上

 実践

2006.2.24 HIROSHIMA CITY


UNIVERSITY
遠隔コラボレーションの普及へ向け 14


アプリケーションの利用可能性の追求
利用場面の分析とそれを実現するアプリケーションの
開発

プ遠
リ隔
ケコ 遠隔コラボレーション普及に向けて,
ーラ 双方の相乗効果が必要
シボ
ョレ
ンー
のシ
開ョ
発ン
を Communication quality

現 Network configuration


利用できる環境の構築
遠隔コラボレーション利用場面の拡 利用の発展

2006.2.24 HIROSHIMA CITY
UNIVERSITY
遠隔コラボレーションシステムと発表論 15


 エンドシステム
 “ 多様な遠隔コラボレーションを実現する音声伝送システム,” 情報処
理学会論文誌 , Vol.45, No.2, pp.517-525, 2004.
 “Development of a Multipurpose Audio Transmission System on the Internet
– To Realize Multiple Audio Communication Scene –“, Proc. of
Human@Society Internet conference 2003, LNCS 2713, pp. 372--382, 2003.
 中間システム
 “An Application Gateway to Deploy High-quality Video Communications in
Various Network Environments”, Proc. of 2006 International Symposium on
Applications and the Internet (SAINT2006) Workshops, pp.26-29, 2006.
 実践とその効果
 “Realization of Active Collaboration in Distance Learning on the Internet,”
JSiSE International Journal of Information and Systems in Education, Vol.2,
No.1, pp.77-84, 2003.
 “Collaborative Learning by Distance Chorus on the Internet”,
Proc. of International Conference on Computers in Education, Vol.1, pp.229-
233, 2002.
2006.2.24 HIROSHIMA CITY
UNIVERSITY
16

多目的音声伝送システム
MRAT

2006.2.24 HIROSHIMA CITY


UNIVERSITY
17
多目的音声伝送システム MRAT
 エンドシステム開発でのアプローチ
 音声伝送技術に着目
 遠隔コラボレーションにおいて映像伝送技術を用いた研究
は数多く成されている (DVTS[5,9], Robst[12], Ruff
Systems[14])

音声伝送技術の従来研究
圧縮技術の効率化 [28] や, VoIP に代表されるように会
話に焦点を当てた物が多い [20][21]
利用場面の多様化に対応することを考慮されていない

 映像伝送技術のみならず,音声伝送技術に着目することでよ
り多くの利用場面に対応できる
2006.2.24 HIROSHIMA CITY
UNIVERSITY
18
利用場面と要求条件
音声のズレ 議論が主で 一方向が主で双方向
が 双方向の会話が多 での会話が少な
一括りに音声伝送といっても利用場面が様々に
許されない い い

     利用 ある
遠隔合唱 遠隔会議 遠隔講演
場面 遠隔合奏 (会話) 遠隔講義

通信の方向性 双方向 双方向 一方向

双方向性 非常に高い 高い 低い

許容遅延時間 100ms 未満 400ms 未満 任意


ITU-T G.114 よ

パケット損失 低  中 高
等の耐性(ロ
バスト性)
主な要求条件 音声のタイミ 会話に支障が 確実に音声を
ングを同期さ ないこと 届けること
せること
ロバスト性が高いほどパケット損失などに対する耐性が強い
2006.2.24 HIROSHIMA CITY
UNIVERSITY
19
MRAT ( Multipurpose RAT)
 多様な利用場面に対応するシステム MRAT
( Multipurpose RAT) の開発
 利用場面ごとに 3 つのモー
ドを持つ
 Chorus モード
  ・・・低遅延
音声伝送
 Conversation モード
 Broadcast モード
・・・ロバスト性の
強化
 IP v6(Unicast, Multicast)
に対応
2006.2.24 HIROSHIMA CITY
UNIVERSITY
20
利用場面と各モードの対応

遅延  ( 転送遅延、処理遅延 )

Broadcast
遠隔講義・遠隔講演
400ms モード
ロバスト性優先

遠隔会議・会話
Conversation
モード 従来の RAT
100ms

Chorus モー 遠隔合唱 この 2 モードを追




低遅延化優先
0ms 低 高
ロバスト性
2006.2.24 HIROSHIMA CITY
UNIVERSITY
21
Chorus モード
 再生バッファ処理の遅延時間を少なくするためのア
ルゴリズム [33]
パラメータ (cushion_max, cushion_min) が CPU や
OS の割り込み性能に依存する

近年の CPU や OS の割り込み性能に合わせ,


パラメータを再検証

低遅延化 (100ms 以内 )

2006.2.24 HIROSHIMA CITY


UNIVERSITY
22
Broadcast モード
 ロバスト性を最大限に重視
ー通信の信頼性を高める方式
  ARQ ( Automatic Repeat
reQuest )
 損失したパケットを自動的に再送する

方法 再送処理のオーバヘッドのためリアルタ
イム伝送に向かない
   FEC ( Forward Error Correction )
送信側  パケット数個ごとに冗長パケットを生成,送信
 パケット損失が発生すれば,冗長パケットから
受信側
復元
再送処理がないためリアルタイム伝送に
向く
 冗長パケットの生成にはブロック符号 Reed-Solom
符号方式を採用  
2006.2.24 HIROSHIMA CITY
UNIVERSITY
23
MRAT の評価

 各モードでの遅延時間の測定
 Broadcast モード
エラー回復能力を理論値と実測値との比較
パケット損失が生じたネットワーク上での実際
の効果
Reed-Solomon FEC と Media-Specific FEC の比

 Chorus モード
パケット損失によるノイズの主観評価
遅延の主観評価
音質の主観評価
2006.2.24 HIROSHIMA CITY
UNIVERSITY
24
遅延時間測定の実験環境

元の音と HostB 経由の 録音用 PC


音の時間軸の差を測定

録音 録音

メトロノーム Host A Host B


送信

Ethernet 100Mbps
CPU PentiumⅢ 600MHz CPU PentiumⅢ   1GHz
2006.2.24 OS Vine Linux2.5 OS Vine Linux2.1
HIROSHIMA CITY
UNIVERSITY
25
遅延時間測定結果

モード 片側の遅延時間
Broadcast
143 [ms]
(15,11)
Broadcast
138 [ms]
(15,12)
Broadcast 全て要求条件
138 [ms]
(15,13) を満たしている
Conversation 132 [ms]
400ms 以下
Chorus 72 [ms]
100ms 以下

この値は十分に速くトラフィックの少ないネットワーク
で測定しており実際の MRAT の処理遅延に近い

実ネットワークではこの値に転送遅延が加算されたものになる
2006.2.24 HIROSHIMA CITY
UNIVERSITY
26
Broadcast モードのエラー回復

疑似乱数 (BSD4.3 準拠の random 関数 ) を用い



パケット独立にパケット損失を発生
パケット損失生成端末
1,2,4,6,8,10% の確率で CPU PentiumⅡ   300MHz
パケット損失発生! OS Vine Linux2.1
LOST

MRAT 100BaseTX MRAT


(Broadcast モー (Broadcast モー
ド) ド)

Host A Host B
FEC デコード後
CPU PentiumⅢ   600MHz CPU PentiumⅢ  のパケット損失率
1GHz
OS Vine Linux2.5 OS Vine Linux2.1 を測定
2006.2.24 HIROSHIMA CITY
UNIVERSITY
10 パケット損失 10 % FEC
測定結果 なし

~ ~
5

(15,13)実測値
4 (15,13)理論値
(15 ,
FEC復元後のパケット損失率 (%)

(15,12)実測値
13)
(15,12)理論値
3 (15,11)実測値
(15,11)理論値
2
(15 , 1
1
2)
FEC あり (15,11) (15 ,
符号 11)
0
0 2 4 6 8 10 12
2006.2.24 27
FEC復元前のパケット損失率 (%)
Media-Specific FEC(MSFEC:RFC2198) との比 28


2

RSFEC(15,8)
FEC回復後のパケット損失率 (%)

RSFEC(15,11)
FEC は冗長コードを生成するため帯域が増加
RSFEC(15,12)
1.4Mbps のストリームの場合
MSFEC
FEC の種類 帯域増加量 使用帯域
Reed-Solomon
1 MSFEC
1.36 倍 1.9Mbps 1.00%
(15,11) 符号
Media Specific 2.00 倍 2.8Mbps

RSFEC
(15,11)
0 0.37%
0 2 4 6 8 10
RSFEC
パケット損失率 (%) (15,8)
2006.2.24
0.01%
HIROSHIMA CITY
UNIVERSITY
MRAT を用いた遠隔コラボレーショ 29


 利用場面にどのような変化をもたらすことがで
きるか
5 年間に渡り 45 例の実証実験
小,中,高等学校や大学の連携授業
遠隔地との伝統芸能交流
遠隔懇話会
遠隔合唱 (Chorus モード )
遠隔合奏 (Chorus モード )
遠隔ゼミ (Broadcast モード )

2006.2.24 HIROSHIMA CITY


UNIVERSITY
Broadcast モードでの実践 30

(2002/4 ~ 2004/12)
3 年間定常利用を行った(計 84 回)
佐賀大学

広島市大-佐賀大 間
Jitter : 4.0 ms
Japan
Packet Loss rate :
Gigabit   0.58
Network ×10-4 %
情報通信研究機構 RTT : 14.8 ms
(NICT)

広島市立大学
広島大学
広島市大-広大 間
各拠点で送信に使用する帯域
Jitter : 6.0 ms
音声: 
Packet Loss rate : 0.12
MRAT(160Kbps) %
2006.2.24 HIROSHIMA CITY
UNIVERSITY
31
Broadcast モードの効果
Reed-Solomon(15,11) 符号を
使用7.0%
FEC適用前
30 秒間音声の途切
6.0% れ FEC適用後
パケット損失率 (%)

5.0%
4.0%
3.0%
2.0%
1.0%
0.0%
0 20 40 60 80 100
経過時間 (sec)

2006.2.24 HIROSHIMA CITY


UNIVERSITY
32
Chorus モードでの実証実験
MRAT

ソプラ
白島小学校(ソプラノ) ノ
伴奏
伴奏+メゾ +アル

MRAT MRAT

FTTH
ゾ 伴奏 ( マルチキャス
70 ~ 75ms10Mbps ト)
伴奏+ソプラ
伴奏
南観音小学校(メゾ) +アルノ 広域 LAN
広島市立大学(伴奏)

アル
MRAT
ト 伴奏+ソプラ エンコード方式 Linear-16 (非圧縮
伴奏 PCM )
サンプリングレー 32kHz
ノ+メゾ
ノ ト
チャンネル モノラル
転送遅延 2.1 ms
基町高校(アルト)
2006.2.24 ジッタ 7.0 ms CITY
HIROSHIMA
UNIVERSITY
33
Chorus モードの効果
 MRAT(Chorus モード ) を使用しなかった場合
片方向遅延 150ms の場合

従来システムでは,遠隔合唱を行うことができない
100ms 以下となる低遅延音声伝送を行うシステムがないと,
インターネットを用いて合唱を行うことそのものが不可能

低遅延伝送を可能とすることで
利用の可能性を広げることができる

2006.2.24 HIROSHIMA CITY


UNIVERSITY
34
ここまでのまとめ
 多目的音声伝送システム MRAT の設計と実装
新たなニーズに対応するため利用場面を分類
多目的な利用用途に対応する実装
パケット損失への対応
– Reed-Solomon 符号を用いた FEC を実装
» Media-Specific FEC(MSFEC:RFC2198) との比較を行
い, MS-FEC と比較して有効性を示した
再生バッファアルゴリズムの見直し
– 72ms という低遅延化を達成
 MRAT を用いた実証実験を通して,利用可能性を広げるこ
とができた
 双方向性の高い遠隔合唱,遠隔合奏
 3 年間の定常運用

2006.2.24小学校,高校において授業への応用 HIROSHIMA CITY
UNIVERSITY
35

プロトコル変換ゲートウェイ

2006.2.24 HIROSHIMA CITY


UNIVERSITY
36
新たな問題点
 様々な実証実験を重ねる上で新たな問題点
異なるネットワークプロトコルの混在
マルチキャスト対応ネットワークと非対応ネット
ワーク
IPv6 の普及により IPv4 と IPv6 の混在した環境の増
I
加 Pv4

NAT, ファイアウォールによる制限 I I
Pv6 Pv6
ネットワークの品質の時間的変動

 様々なネットワーク環境により,相互に通信が行
異なる環境下においても遠隔コラボレーションが
えない環境も出現
実現可能となる環境を創ることが重要
    
2006.2.24 HIROSHIMA CITY
UNIVERSITY
37
中間システム PTGATE の特徴
 アプリケーションレベルでの転送処理を実現
長所
IP 層でのプロトコルの差異をアプリケーションで吸収
ネットワーク状況やアプリケーションによって利用機能
の変更が容易
IP ストリーム伝送における付加機能を提供
– パケット損失回復機能
– アプリケーションに特化した制御
» ストリーム毎に必要な機能を選択

短所
アプリケーション処理によるオーバーヘッド
– カプセル化による帯域増加
– 処理遅延(ジッタ)の発生

2006.2.24 HIROSHIMA CITY


UNIVERSITY
38
中間システム PTGATE の設計
 IP-in-IP を基本とした構成
IP 層でのプロトコルの差異を中間システムが吸収
既存のシステムに次世代インフラストラクチャで必
要な機能を提供
従来方式
特定アプリケーションにのみ対応
PTGATE

FEC 機能 新井 2003, 加島 2002

TV 会議 ポート集約機能
H.323 のみ対応
システム IPv6/v4 トンネル機能 RFC3056, 屏 2004

マルチキャストトンネル機能 Peter Pernes1997

IPv4/v6 トンネル機能やマルチキャストトンネル機能のみを提供
ISDN リンクなどの狭帯域ネットワー
クへいかに伝送するかという事を
複数機能をまとめて付加できない
2006.2.24 HIROSHIMA CITY
重視 UNIVERSITY
39
PTGATE の動作概要

IP UDPIPPTGW
IP UDP PTGW
GW1 IP GW2
Payload Payload

機能補完が必要な
0     7     15  
      31 ネットワーク
V P X reserve payload type sequence number
冗長化 パケット回復
timestamp
ポート集約 ポート集約解除
Sender next header Receiver
PTGATE 1 header
V4/v6size reserve 2
V4/v6 脱カプセル PTGATE
カプセル
code symbol size number of data化 化 SN base
max payload size payload size
対向の PTGATE を指定し,どのような機能補完を行うか指定する
エンドシステムは通常の使用通り送信先を Receiver を指定し
デフォルトゲートウェイは PTGATE に向ける
2006.2.24 HIROSHIMA CITY
UNIVERSITY
40
開発環境と動作確認
 実装
 PF_PACKET を用いた実装
 ユーザランドで動作
 Linux 上で動作可
 開発環境

OS Fedora core 2 (kernel 2.6.9)


Redhat Linux 8.0 (kernel 2.4.28)
CPU Pentium 4 3.2GHz
Memory 1GB

 動作確認
 Vine Linux 2.6, 3.0, 3.1(kernel 2.4.28)
 Debian (kernel 2.4.18)
 Fedora core 2 (kernel 2.6.9)
 Redhat Linux 8.0, 9.0(kernel 2.4.28)
 Knoppix 3.6(kernel 2.4.27) (using USB memory stick)
2006.2.24 HIROSHIMA CITY
UNIVERSITY
41
PTGATE で使用可能なシステム
動作確認を行ったシステム
 VIC/RAT 従来システムと比較して
 VideoLAN より多くのシステムに対応可能
 DVTS
 Robst
 Netmeeting
 GnomeMeeting
H.323 を使用したシステム
 Polycom Viewstation
 Sony PCS-1
 Victor DM-NE300/ND300 市販のハードウェア製品
独自の呼制御方式
 OKI Visualcast-SS
2006.2.24 HIROSHIMA CITY
UNIVERSITY
42

PTGATE の評価
 評価項目
基本性能評価(オーバヘッド)
UDP 転送レート
30Mbps 程度の広帯域を伝送する
RTT
システムでも十分に利用可能
ジッタ
各機能の実証実験
マルチキャストトンネル機能 (3 大学合同
ゼミ )
IPv6/IPv4 トンネル機能 ( 札幌雪祭り配信 )
FEC 機能 ( 学内 LAN)
誤り訂正能力
2006.2.24 HIROSHIMA CITY
UNIVERSITY
実証実験Ⅰ - マルチキャスト通信の問題の解決 43

( マルチキャストトンネル機能 )

広島大学

広島市立大学
Japan
Gigabit Multicast
Multicast
Network 佐賀大学
情報通信研究機
構 (NICT)

Multicast
音声伝送システム マルチキャスト通信不可
MRAT(128kbps) 途中経路のルータの設定
Multicast
ベンダ間の相互通信の問題

2006.2.24 HIROSHIMA CITY


UNIVERSITY
実証実験Ⅰ - マルチキャスト通信の問題の解決 44

( マルチキャストトンネル機能 )

広島大学

広島市立大学 PTGATE
Japan
Gigabit Multicast
Multicast
Network 佐賀大学
PTGATE 情報通信研究機
Multicast 構 (NICT)

PTGATE
音声伝送システム : Multicast Tunnel
PTGATE のマルチキャストトンネル機能を用いることで
MRAT(128kbps)
既存ネットワークのまま運用を行うことができる
Multicast

2006.2.24 HIROSHIMA CITY


UNIVERSITY
実証実験Ⅱ - 広域配送時の問題の解決 45

(IPv6/IPv4 トンネル機能 )
JGNv6 Network  

Japan
IPv6
Multicast
Gigabit
IPv6 IPv4 カプセル化
Network
Robst 情報通信研究機構
IPv4
札幌
PTGATE Hiroshima City Univ. IPv6 通信不可 

地域間相互接続 RIBB2 Network


Multicast
プロジェクト
IPv6
IPv4 脱カプセル化 RIBB
PTGATE

PTGATE

PTGATE
山梨
富山
2006.2.24 高知 HIROSHIMA CITY
UNIVERSITY
46
実証実験Ⅱ - FEC 機能による効果

富山 高知 山梨
パケット損失数
59694 59737 59738
(FEC 前 )
パケット損失数
429 446 438
(FEC 前 )
パケット損失率
0.4493 0.4504 0.4504
(FEC 前 )[%]
パケット損失率
0.0032 0.0034 0.0033
(FEC 後 )[%]
ジッタ (ms) 1.1020 0.8750 1.1396

2006.2.24 HIROSHIMA CITY


UNIVERSITY
47

研究のまとめ

2006.2.24 HIROSHIMA CITY


UNIVERSITY
48
研究のまとめ
 遠隔コラボレーションシステムの設計と実装
多目的音声伝送システム MRAT ( エンドシステム )
プロトコル変換ゲートウェイ PTGATE ( 中間システ
ム)

 実証実験により遠隔コラボレーションの実践
遠隔合唱,遠隔合奏
遠隔ゼミ
札幌雪祭り広域配信実験

2006.2.24 HIROSHIMA CITY


UNIVERSITY
49
研究のまとめ(続き)
本研究により達成されたこと

問題点
問題点1
  次世代インフラストラクチャとアプリケーションとの
ギャップ
解決方法

MRAT による低遅延,ロバスト性の高いシステムの
開発
中間システムにより IP 層のプロトコルの差異を吸
収するシステムの開発
様々な実証実験を行い,ブロードバンドアプリケー
ションの利用可能性を広げることを実践
イベント的な利用だけではなく定常的な運用
2006.2.24 HIROSHIMA CITY
UNIVERSITY
50
研究のまとめ(続き)
問題点2 RTPの利用と次世代インフラストラクチャとの
問題点
ギャップ
解決方法
 解決
 パケット損失への対応
Reed-Solomon 符号を用いた FEC の実装
 再生バッファアルゴリズムの見直し
72ms となる低遅延伝送の達成
問題点 3
解決方法
問題 ネットワーク仕様やニーズの多様化に因る問題
 解決
 新たに想定される利用場面の分析,機能設計
 中間システムにより広域配送時の問題の解消
これらの問題点を解決することで
遠隔コラボレーションの普及へ貢献
2006.2.24 HIROSHIMA CITY
UNIVERSITY
51
開発したシステムの適用範囲
 MRAT の適用範囲
FEC に Reed-Solomon 符号を使用することの限界
ブロック符号の特性上大きなバースト損失に対応し
ようとすると,演算の処理負荷が大きくなる
Chorus モードの利用できる範囲
データの転送速度の限界により合唱できる範囲に制
限が生じる
音声に比べ映像伝送のほうが処理遅延が大きくな
る傾向にある
MRATと他の映像伝送システムを併用すると映像と音
声が同期しない

2006.2.24 HIROSHIMA CITY


UNIVERSITY
52
開発したシステムの適用範囲 ( 続き )
 PTGATE の適用範囲
ポート集約機能を用いてもファイアウォールに穴
を開ける必要がある
現在は PTGATE 間のトポロジを制御できる機構が
ない
応用用途を広げるためには必要である
PC の仕様や NIC の仕様により数 Gbps を利用する
アプリケーションには使用できない

2006.2.24 HIROSHIMA CITY


UNIVERSITY
53
今後の課題と展望
 今後の課題
 PTGATE のトポロジ管理機能
 運用を支援する GUI の開発
 今後の展望
 さらなる遠隔コラボレーションの普及を目指す
教育現場
– どこでも授業が受けられる
– 縦の関係を越えた授業 ( 大学ー高校 )
エンターテイメント
– 遠隔地でのレコーディング
– 音楽ライブ

2006.2.24 HIROSHIMA CITY


UNIVERSITY
参考資料

HIROSHIMA CITY
UNIVERSITY
55
Media Specific FEC との比較

 RAT には Media Specific FEC ( RFC2198) が実装されている

primar secondar
エンコード方式を個々に選択でき y y
Linear-16(PCM) PCMμ-law

音声データパケットを複

送信ホス

次のパケットにくっつけて送

欠落したパケットがあれば一
つ後のパケットにくっついて 受信ホス
いたものから復元 ト

2006.2.24 HIROSHIMA CITY


UNIVERSITY
56
Media Specific FEC との比較

 RAT に実装されている Media Specific FEC と今回新たに実装した


Reed-Solomon FEC との比較を行った

エンコード方式 Linear-16 ,サンプリング周波数 32kHz ,モノラルの場


合FEC の種類 使用帯域 帯域増加量
なし 512 [kbps] (1.0 倍 )
Reed-Solomon FEC (15,13) 591 [kbps] 1.15 倍
 
(15,12) 640 [kbps] 1.25 倍
 
(15,11) 698 [kbps] 1.36 倍
 
(15,8) 960 [kbps] 1.88 倍
Media Specific FEC linear-16※ 1024 2.0 倍
※secondary encoding に linear-16 を用いた場合[kbps]

パケット損失 20% 下でのそれぞれの FEC の音質の比較


パケット損失 20%
Reed-
MediaSpecificFEC
2006.2.24 HIROSHIMA CITY
Solomon(15,8)
の時 UNIVERSITY
57
パリティ符号を用いた FEC との比較

5
RS(15,13)code理論値
RS(15,12)code理論値
Packet loss rate after FEC recovery (%)

4 RS(15,11)code理論値
Parity(2,1)code理論値

3 Parity(3,2)code理論値
Parity(4,3)code理論値
Parity(5,4)code理論値
2
Parity(6,5)code理論値

0
0 2 4 6 8 10 12
Packet Loss rate before FEC recovery (%)

“ 高品質動画像伝送における FEC の性能評価,”


2006.2.24
情報処理学会論文誌 , Vol.45, No.1, pp.84-92,
HIROSHIMA CITY
2004. UNIVERSITY
58
他の符号方式との検討
 誤り訂正符号を IP パケットに適用したもの
Media-Specific FEC(RFC2198)
Parity 符号を用いた FEC(RFC2733)
新井らの方式
畳込み符号
パケット損失が比較的低く,余り変化しないような通信
路において効果的と結論

M. Arai et al."A Study on Extention of Coefficients for (n, k, m) Convolutional-Code-Based


FEC,"
Proc. of 2nd Euro-Japanese Workshop on Stochastic Risk Modelling for Finance,
Insurance, Production and Reliability, pp. 32-41 (2002).

2006.2.24 HIROSHIMA CITY


UNIVERSITY
59
パリティ符号を用いた FEC との比較

Reed-Solomon 符号 パリティ符号
FEC 帯域増加量 FEC 帯域増加量
[倍] [倍]
(15, 13) 1.15 (6, 5) 1.2
(15, 12) 1.25 (5, 4) 1.25
(15, 11) 1.36 (4, 3) 1.33
(3, 2) 1.5
パケット損失 10% の
場合 (2, 1) 2.0
RS(15,12) 1.27%
1.25 倍の帯域となる RS(15,12) 符
Parity(5,4) 3.44% 号と
2006.2.24 パリティ (5,4) 符号との比較
HIROSHIMA CITY
UNIVERSITY
60
DCCP (Datagram Congestion Control Protocol)

 UDP の Next Generation という位置づけ


 現在 Internet Draft
 実時間通信のために設計されたプロトコル
 UDP +輻輳制御
 輻輳制御のアルゴリズムを選択可能
CCID2
CCID3

2006.2.24 HIROSHIMA CITY


UNIVERSITY
61
SCTP (Stream Control Transmission Protocol)

 3 つの転送方式を持つ
Strict orderd mode(RFC2960)
TCP と同様に厳密な順序制御を行う
Unorderd mode
UDP のように順序制御を行わない
Partial orderd mode
SCTP Partial Reliability Extension (RFC 3758)
– 一部分のみ順序制御

2006.2.24 HIROSHIMA CITY


UNIVERSITY
62
バースト損失の検討
 RS(15,11) 符号では, 1 ブロック中に最大 4 つ
までの連続したパケット損失を回復可能
 回復可能はバースト損失は冗長度に依存する
例えば, RS(255,232) 符号を用いた場合
1 ブロック中に最大 23 個までバースト損失に対応できる

 より多くの連続したパケット損失を回復するた
めには,冗長度を上げる必要がある.冗長度を
上げると帯域が増加する
バースト耐性と帯域増加率はトレードオフの関係

2006.2.24 HIROSHIMA CITY


UNIVERSITY
63
QoS パラメータの例

QoS のレベル 映像 音声 コンピュータデー



ユーザ MOS (Mean Opinion Score) ,心理的尺度

アプリケー PSNR, フレー PESQ, サンプ 遅延,因果順序逆


ション ムレート,解 リングレー 転率
像度,符号化 ト,符号化方
方式 式
ネットワーク スループット, PDU 遅延, PDU 揺らぎ, PDU 欠
落率
ユーザ 伝送速度,信号対雑音電力費 (SNR) ,ビット誤り率

2006.2.24 HIROSHIMA CITY


UNIVERSITY
64
JGN2 のトラフィックの様子
札幌雪祭り配信実
験 -1
 JGN2  アクセスポイント 北海道

 JGN2  アクセスポイント 沖縄 -1

2006.2.24 HIROSHIMA CITY


UNIVERSITY

You might also like