Professional Documents
Culture Documents
遠隔コラボレーションに関する
研究
広島市立大学大学院 博士後期課程
情報科学研究科 情報科学専攻
コンピュータ情報科学系
岸田 崇志
HIROSHIMA CITY
UNIVERSITY
2
発表概要
研究の背景と目的
次世代ブロードバンドアプリケーションに
おける問題点
遠隔コラボレーションシステム
多目的音声伝送システム MRAT
MRAT を用いた実践
プロトコル変換ゲートウェイ PTGATE
研究のまとめ
研究の背景と目的
るもの
新たな利用方法に対応すること
新たな利用要求が生まれてきている
※ 現在は会話が中心
対面のコミュニケーションにより近づくこと
双方向性が高いこと
高品質な映像や音声
映像では, 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
研究の目的
遠隔コラボレーションを実現するために
多様化するニーズにおいて要求条件をまとめる
こと
要求条件を満たし,次世代インフラストラクチャを
活用
するブロードバンドアプリケーションの開発を行う
こと
日常的な利用に向けて,多くの遠隔コラボレーショ
ンの
利活用を進めること
て
アプリケーションの利用可能性の追求
利用場面の分析とそれを実現するアプリケーションの
開発
リ遠
ケ隔
ーコ 遠隔コラボレーション普及に向けて,
シラ 双方の相乗効果が必要
ョボ
ンレ
のー
開シ
発ョ
ン
を Communication quality
実
現 Network configuration
す
る
ア
プ
利用できる環境の構築
遠隔コラボレーションの利用場面の拡 利用の発展
大
2006.2.24 HIROSHIMA CITY
UNIVERSITY
11
遠隔コラボレーションシステム
遠隔コラボレーションシステムの設計と開発
開発には二つのアプローチを採用
エンドシステム
エンドシステム
利用場面における要求条件の分析
要求条件を満たす実装
中間システム
中間システム
多様なネットワーク仕様に適応する
インターオペラビリティの向上
実践
て
アプリケーションの利用可能性の追求
利用場面の分析とそれを実現するアプリケーションの開
発
プ遠
リ隔
ケコ 遠隔コラボレーション普及に向けて,
ーラ 双方の相乗効果が必要
シボ
ョレ
ンー
のシ
開ョ
発ン
を Communication quality
実
現 Network configuration
す
る
ア
利用できる環境の構築
遠隔コラボレーション利用場面の拡 利用の発展
大
2006.2.24 HIROSHIMA CITY
UNIVERSITY
13
遠隔コラボレーションシステム
遠隔コラボレーションシステムの設計と開発
開発には二つのアプローチを採用
エンドシステム
エンドシステム
アプリケーションの要求条件の分析
要求条件を満たす実装
中間システム
中間システム
多様なネットワーク仕様に適応する
インターオペラビリティの向上
実践
て
アプリケーションの利用可能性の追求
利用場面の分析とそれを実現するアプリケーションの
開発
プ遠
リ隔
ケコ 遠隔コラボレーション普及に向けて,
ーラ 双方の相乗効果が必要
シボ
ョレ
ンー
のシ
開ョ
発ン
を 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
音声伝送技術の従来研究
圧縮技術の効率化 [28] や, VoIP に代表されるように会
話に焦点を当てた物が多い [20][21]
利用場面の多様化に対応することを考慮されていない
映像伝送技術のみならず,音声伝送技術に着目することでよ
り多くの利用場面に対応できる
2006.2.24 HIROSHIMA CITY
UNIVERSITY
18
利用場面と要求条件
音声のズレ 議論が主で 一方向が主で双方向
が 双方向の会話が多 での会話が少な
一括りに音声伝送といっても利用場面が様々に
許されない い い
利用 ある
遠隔合唱 遠隔会議 遠隔講演
場面 遠隔合奏 (会話) 遠隔講義
双方向性 非常に高い 高い 低い
遅延 ( 転送遅延、処理遅延 )
Broadcast
遠隔講義・遠隔講演
400ms モード
ロバスト性優先
遠隔会議・会話
Conversation
モード 従来の RAT
100ms
低遅延化 (100ms 以内 )
方法 再送処理のオーバヘッドのためリアルタ
イム伝送に向かない
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
遅延時間測定の実験環境
録音 録音
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 モードのエラー回復
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 モード )
(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)
ソプラ
白島小学校(ソプラノ) ノ
伴奏
伴奏+メゾ +アル
ト
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 以下となる低遅延音声伝送を行うシステムがないと,
インターネットを用いて合唱を行うことそのものが不可能
低遅延伝送を可能とすることで
利用の可能性を広げることができる
プロトコル変換ゲートウェイ
NAT, ファイアウォールによる制限 I I
Pv6 Pv6
ネットワークの品質の時間的変動
様々なネットワーク環境により,相互に通信が行
異なる環境下においても遠隔コラボレーションが
えない環境も出現
実現可能となる環境を創ることが重要
2006.2.24 HIROSHIMA CITY
UNIVERSITY
37
中間システム PTGATE の特徴
アプリケーションレベルでの転送処理を実現
長所
IP 層でのプロトコルの差異をアプリケーションで吸収
ネットワーク状況やアプリケーションによって利用機能
の変更が容易
IP ストリーム伝送における付加機能を提供
– パケット損失回復機能
– アプリケーションに特化した制御
» ストリーム毎に必要な機能を選択
短所
アプリケーション処理によるオーバーヘッド
– カプセル化による帯域増加
– 処理遅延(ジッタ)の発生
TV 会議 ポート集約機能
H.323 のみ対応
システム IPv6/v4 トンネル機能 RFC3056, 屏 2004
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 上で動作可
開発環境
動作確認
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
ベンダ間の相互通信の問題
( マルチキャストトンネル機能 )
広島大学
広島市立大学 PTGATE
Japan
Gigabit Multicast
Multicast
Network 佐賀大学
PTGATE 情報通信研究機
Multicast 構 (NICT)
PTGATE
音声伝送システム : Multicast Tunnel
PTGATE のマルチキャストトンネル機能を用いることで
MRAT(128kbps)
既存ネットワークのまま運用を行うことができる
Multicast
(IPv6/IPv4 トンネル機能 )
JGNv6 Network
Japan
IPv6
Multicast
Gigabit
IPv6 IPv4 カプセル化
Network
Robst 情報通信研究機構
IPv4
札幌
PTGATE Hiroshima City Univ. IPv6 通信不可
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
研究のまとめ
実証実験により遠隔コラボレーションの実践
遠隔合唱,遠隔合奏
遠隔ゼミ
札幌雪祭り広域配信実験
問題点
問題点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と他の映像伝送システムを併用すると映像と音
声が同期しない
HIROSHIMA CITY
UNIVERSITY
55
Media Specific FEC との比較
primar secondar
エンコード方式を個々に選択でき y y
Linear-16(PCM) PCMμ-law
る
音声データパケットを複
製
送信ホス
ト
次のパケットにくっつけて送
信
欠落したパケットがあれば一
つ後のパケットにくっついて 受信ホス
いたものから復元 ト
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 (%)
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)
3 つの転送方式を持つ
Strict orderd mode(RFC2960)
TCP と同様に厳密な順序制御を行う
Unorderd mode
UDP のように順序制御を行わない
Partial orderd mode
SCTP Partial Reliability Extension (RFC 3758)
– 一部分のみ順序制御
より多くの連続したパケット損失を回復するた
めには,冗長度を上げる必要がある.冗長度を
上げると帯域が増加する
バースト耐性と帯域増加率はトレードオフの関係
JGN2 アクセスポイント 沖縄 -1