1. インターネット上の高品質な 遠隔コラボレーションに関する研究 広島市立大学大学院 博士後期課程 情報科学研究科 情報科学専攻 コンピュータ情報科学系 岸田 崇志

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

3. 研究の背景と目的

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

5. これからのコミュニケーションに望まれるもの 新たな利用方法に対応すること 新たな利用要求が生まれてきている ※ 現在は会話が中心 対面のコミュニケーションにより近づくこと 双方向性が高いこと 高品質な映像や音声 映像では，SDTV品質以上．音声では，電話品質を上回るもの パケット損失の影響が少ないこと 遠隔コラボレーションの実現によりネットワークを意識せず 現実のコミュニケーションと同じことが行える環境へ 双方向性が高く高品質なインターネット上の コミュニケーションを遠隔コラボレーションと定義

6. 問題点１： 次世代インフラストラクチャとアプリケーションとのギャップ JGN II ：日本 (20Gbps) vBNS ：米国 (10Gbps) Abilene ：米国 (2.4Gbps) CA*net 4 ：カナダ (10Gbps) 広帯域，高品質，次世代プロトコル インフラストラクチャの整備と比較して アプリケーションの開発や利用が進んでいない アプリケーションの 開発・利用 次世代インフラストラクチャ の整備 遠隔コラボレーションを行える環境が築かれている 研究機関を中心に利用 定常的な利用に至っていない

7. 問題点２： ＲＴＰの利用と次世代インフラストラクチャとのギャップ リアルタイム通信を行うプロトコル RTP(RFC3550) 多くのアプリケーションに実装 パケット損失の問題 同じパケット損失率でも影響が大きく違う 再生バッファの問題 RTP では遅延の揺らぎを吸収し，一定の間隔で再生を行うためのバッファ機構がある バッファ機構と低遅延伝送は トレードオフ 低遅延伝送を目指すためには，揺らぎを吸収するだけでなく バッファ長を見積もる機構を見直す必要がある パケット損失に対する扱いを検討する必要がある Ex.) パケット損失率 1 % の場合 VIC (700kbps) 80pps 1 秒間のパケット損失数 0.8 パケット (5 秒に 4 パケット損失 ) DVTS (30Mbps) 3000pps 1 秒間のパケット損失数 30 パケット 従来アプリケーション 広帯域アプリケーション

8. 問題点３： ネットワーク仕様やニーズの多様化に因る問題 ネットワーク仕様の多様化に因る問題 異なるネットワークプロトコルの混在 マルチキャスト対応ネットワークと非対応ネットワーク IPv4 環境と IPv6 環境 今後は IPv6 の普及により，より混在していく 広域配送時において問題がより顕著に NAT ， Firewall 機器による通信の制限 ニーズの多様化に因る問題 従来のアプリケーションでは実現不可能な利用要求 ネットワーク環境に因らず相互通信を可能にする環境を創り出す必要がある 新たなニーズに応えるアプリケーションの開発が必要

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

10. 遠隔コラボレーションの普及へ向けて 遠隔コラボレーションを実現するアプリケーションの開発 遠隔コラボレーションの利用場面の拡大 遠隔コラボレーション普及に向けて，双方の相乗効果が必要 利用できる環境の構築 利用の発展 アプリケーションの利用可能性の追求 利用場面の分析とそれを実現するアプリケーションの開発 Communication quality Network configuration

11. 遠隔コラボレーションシステム 遠隔コラボレーションシステムの設計と開発 開発には二つのアプローチを採用 エンドシステム 利用場面における要求条件の分析 要求条件を満たす実装 中間システム 多様なネットワーク仕様に適応する インターオペラビリティの向上 実践 エンドシステム 中間システム

12. 遠隔コラボレーションの普及へ向けて アプリケーションの利用可能性の追求 利用場面の分析とそれを実現するアプリケーションの開発 遠隔コラボレーションを実現するアプリケーションの開発 遠隔コラボレーション利用場面の拡大 遠隔コラボレーション普及に向けて，双方の相乗効果が必要 Communication quality Network configuration 利用できる環境の構築 利用の発展

13. 遠隔コラボレーションシステム 遠隔コラボレーションシステムの設計と開発 開発には二つのアプローチを採用 エンドシステム アプリケーションの要求条件の分析 要求条件を満たす実装 中間システム 多様なネットワーク仕様に適応する インターオペラビリティの向上 実践 エンドシステム 中間システム

14. 遠隔コラボレーションの普及へ向けて 利用できる環境の構築 利用の発展 遠隔コラボレーションを実現するアプリケーションの開発 遠隔コラボレーション利用場面の拡大 遠隔コラボレーション普及に向けて，双方の相乗効果が必要 Communication quality Network configuration アプリケーションの利用可能性の追求 利用場面の分析とそれを実現するアプリケーションの開発

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.

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

17. 多目的音声伝送システムMRAT エンドシステム開発でのアプローチ 音声伝送技術に着目 遠隔コラボレーションにおいて映像伝送技術を用いた研究は数多く成されている (DVTS[5,9], Robst[12], Ruff Systems[14]) 音声伝送技術の従来研究 圧縮技術の効率化 [28] や， VoIP に代表されるように会話に焦点を当てた物が多い [20][21] 利用場面の多様化に対応することを考慮されていない 映像伝送技術のみならず，音声伝送技術に着目することでより多くの利用場面に対応できる

18. 利用場面と要求条件 一括りに音声伝送といっても利用場面が様々にある 一方向が主で双方向での会話が少ない 議論が主で 双方向の会話が多い 音声のズレが 許されない 低い 高い 非常に高い 双方向性 確実に 音声を届けること 会話に支障がないこと 音声のタイミングを 同期させる こと 主な要求条件 高 中 低 パケット損失等の耐性（ ロバスト性 ） 任意 400ms 未満 ITU-T G.114 より 100ms 未満 許容遅延時間 一方向 双方向 双方向 通信の方向性 遠隔講演 遠隔講義 遠隔会議 （会話） 遠隔合唱 遠隔合奏 利用場面 ロバスト性 が高いほどパケット損失などに対する耐性が強い

19. MRAT（Multipurpose RAT) 利用場面ごとに 3 つのモードを持つ Chorus モード ・・・低遅延音声伝送 Conversation モード Broadcast モード ・・・ロバスト性の強化 ＩＰ v6(Unicast, Multicast) に対応 多様な利用場面に対応するシステム MRAT （ Multipurpose RAT) の開発

20. 利用場面と各モードの対応 遠隔合唱 遠隔講義・遠隔講演 遠隔会議・会話 100ms 400ms 遅延 ( 転送遅延、処理遅延 ) 低 高 0ms ロバスト性 従来の RAT 低遅延化優先 ロバスト性優先 Chorus モード Conversation モード Broadcast モード この 2 モードを追加

21. Chorusモード 再生バッファ処理の遅延時間を少なくするためのアルゴリズム [33] パラメータ ( cushion_max, cushion_min) が CPU や OS の割り込み性能に依存する 近年の CPU や OS の割り込み性能に合わせ， パラメータを再検証 低遅延化 (100ms 以内 )

22. Broadcastモード ロバスト性を最大限に重視 損失したパケットを自動的に再送する方法 ARQ （ Automatic Repeat reQuest ） FEC （ Forward Error Correction ） 冗長パケットの生成にはブロック符号 Reed-Solomon 符号方式を採用 ー通信の信頼性を高める方式 送信側 受信側 パケット数個ごとに冗長パケットを生成，送信 パケット損失が発生すれば，冗長パケットから復元 再送処理のオーバヘッドのためリアルタイム伝送に向かない 再送処理がないためリアルタイム伝送に向く

23. MRAT の評価 各モードでの遅延時間の測定 Broadcastモード エラー回復能力を理論値と実測値との比較 パケット損失が生じたネットワーク上での実際の効果 Reed-Solomon FECとMedia-Specific FECの比較 Chorusモード パケット損失によるノイズの主観評価 遅延の主観評価 音質の主観評価

24. 遅延時間測定の実験環境 Ethernet 100Mbps 録音 録音 CPU PentiumⅢ 600MHz OS Vine Linux2.5 CPU PentiumⅢ 1GHz OS Vine Linux2.1 Host A Host B 録音用 PC メトロノーム 送信 元の音と HostB 経由の 音の時間軸の差を測定

25. 遅延時間測定結果 全て要求条件 を満たしている 400ms以下 100ms以下 ７２ [ms] １３２ [ms] １３８ [ms] １３８ [ms] １４３ [ms] 片側の遅延時間 Chorus Conversation Broadcast (15,13) Broadcast (15,12) Broadcast (15,11) モード この値は十分に速くトラフィックの少ないネットワーク で測定しており実際の MRAT の処理遅延に近い 実ネットワークではこの値に転送遅延が加算されたものになる

26. Broadcast モードのエラー回復 100BaseTX CPU Pentium Ⅱ 300MHz OS Vine Linux2.1 CPU Pentium Ⅲ 600MHz OS Vine Linux2.5 CPU Pentium Ⅲ 1GHz OS Vine Linux2.1 1,2,4,6,8,10% の確率でパケット損失発生！ LOST MRAT (Broadcast モード ) MRAT (Broadcast モード ) パケット損失生成端末 Host A Host B FECデコード後 のパケット損失率 を測定 疑似乱数(BSD4.3準拠のrandom関数)を用いて パケット独立にパケット損失を発生

27. 測定結果 ( 15 ， 13) (15 ， 12) (15 ， 11) FEC あり (15,11) 符号 パケット損失 10 ％ FEC なし 10 ～ ～ ～ ～

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

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

30. Broadcast モードでの実践 (2002/4 ～ 2004/12) Japan Gigabit Network Jitter ： 4.0 ms Packet Loss rate ： 0.58 ×10 -4 % RTT ： 14.8 ms Jitter ： 6.0 ms Packet Loss rate ： 0.12 % RTT ： 8.5 ms 3 年間定常利用を行った（計 84 回） 情報通信研究機構 (NICT) 佐賀大学 広島大学 広島市立大学 広島市大－広大 間 広島市大－佐賀大 間 音声： MRAT(160Kbps) 映像： Mpeg2ts(5Mbps) 各拠点で送信に使用する帯域

31. Broadcastモードの効果 Reed-Solomon(15,11) 符号を使用 30 秒間音声の途切れ

32. Chorus モードでの実証実験 FTTH 10Mbps 広域 LAN 基町高校（アルト） 南観音小学校（メゾ） 白島小学校（ソプラノ） 広島市立大学（伴奏） 伴奏 MRAT MRAT MRAT MRAT 7.0 ms ジッタ 2.1 ms 転送遅延 モノラル チャンネル 32kHz サンプリングレート Linear-16 （非圧縮 PCM ） エンコード方式 伴奏 ( マルチキャスト ) 伴奏 伴奏 ソプラノ メゾ アルト 伴奏＋ソプラノ 伴奏＋ソプラノ 伴奏＋メゾ 伴奏＋ソプラノ＋メゾ ＋アルト ＋アルト 70 ～ 75ms

33. Chorusモードの効果 MRAT(Chorus モード ) を使用しなかった場合 片方向遅延 150ms の場合 低遅延伝送を可能とすることで 利用の可能性を広げることができる 100ms 以下となる低遅延音声伝送を行うシステムがないと， インターネットを用いて合唱を行うことそのものが不可能 従来システムでは，遠隔合唱を行うことができない

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

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

36. 新たな問題点 様々な実証実験を重ねる上で新たな問題点 異なるネットワークプロトコルの混在 マルチキャスト対応ネットワークと非対応ネットワーク IPv6 の普及により IPv4 と IPv6 の混在した環境の増加 NAT,ファイアウォールによる制限 ネットワークの品質の時間的変動 様々なネットワーク環境により，相互に通信が行えない環境も出現 異なる環境下においても遠隔コラボレーションが 実現可能となる環境を創ることが重要 IPv6 IPv4 IPv6

37. 中間システムPTGATEの特徴 アプリケーションレベルでの転送処理を実現 長所 IP層でのプロトコルの差異をアプリケーションで吸収 ネットワーク状況やアプリケーションによって利用機能の変更が容易 IPストリーム伝送における付加機能を提供 パケット損失回復機能 アプリケーションに特化した制御 ストリーム毎に必要な機能を選択 短所 アプリケーション処理によるオーバーヘッド カプセル化による帯域増加 処理遅延（ジッタ）の発生

38. 中間システムPTGATEの設計 IP-in-IP を基本とした構成 IP層でのプロトコルの差異を中間システムが吸収 既存のシステムに次世代インフラストラクチャで必要な機能を提供 TV 会議 システム H.323 のみ対応 IPv4/v6 トンネル機能やマルチキャストトンネル機能のみを提供 複数機能をまとめて付加できない ISDN リンクなどの狭帯域ネットワークへいかに伝送するかという事を重視 特定アプリケーションにのみ対応 FEC 機能 ポート集約機能 マルチキャストトンネル機能 IPv6/v4 トンネル機能 PTGATE 従来方式 新井 2003, 加島 2002 RFC3056, 屏 2004 Peter Pernes1997

39. PTGATEの動作概要 GW2 GW1 機能補完が必要なネットワーク Sender Receiver 冗長化 ポート集約 V4/v6カプセル化 パケット回復 ポート集約解除 V4/v6脱カプセル化 対向の PTGATE を指定し，どのような機能補完を行うか指定する エンドシステムは通常の使用通り送信先を Receiver を指定し デフォルトゲートウェイは PTGATE に向ける PTGATE 1 PTGATE 2 IP UDP PTGW IP Payload IP UDP PTGW IP Payload reserve payload size max payload size SN base number of data code symbol size reserve header size next header timestamp sequence number payload type V P X 0 7 15 31

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) 1GB Memory Pentium 4 3.2GHz CPU Fedora core 2 (kernel 2.6.9) Redhat Linux 8.0 (kernel 2.4.28) OS

41. PTGATEで使用可能なシステム VIC/RAT VideoLAN DVTS Robst Netmeeting GnomeMeeting Polycom Viewstation Sony PCS-1 Victor DM-NE300/ND300 OKI Visualcast-SS 動作確認を行ったシステム 従来システムと比較して より多くのシステムに対応可能 市販のハードウェア製品 H.323 を使用したシステム 独自の呼制御方式

42. PTGATEの評価 評価項目 基本性能評価（オーバヘッド） UDP 転送レート ＲＴＴ ジッタ 各機能の実証実験 マルチキャストトンネル機能 (3 大学合同ゼミ ) IPv6/IPv4 トンネル機能 ( 札幌雪祭り配信 ) FEC 機能 ( 学内 LAN) 誤り訂正能力 30Mbps 程度の広帯域を伝送する システムでも十分に利用可能

43. 実証実験Ⅰ - マルチキャスト通信の問題の解決 ( マルチキャストトンネル機能 ) 音声伝送システム MRAT(128kbps) Japan Gigabit Network 情報通信研究機構 (NICT) Multicast Multicast Multicast マルチキャスト通信不可 途中経路のルータの設定 ベンダ間の相互通信の問題 Multicast 広島市立大学 広島大学 佐賀大学

44. 実証実験Ⅰ - マルチキャスト通信の問題の解決 ( マルチキャストトンネル機能 ) 音声伝送システム MRAT(128kbps) Japan Gigabit Network 情報通信研究機構 (NICT) Multicast Multicast Multicast PTGATE のマルチキャストトンネル機能を用いることで 既存ネットワークのまま運用を行うことができる 広島市立大学 広島大学 佐賀大学 PTGATE PTGATE PTGATE ： Multicast Tunnel Multicast

45. 実証実験Ⅱ - 広域配送時の問題の解決 (IPv6/IPv4 トンネル機能 ) 地域間相互接続 プロジェクト RIBB Japan Gigabit Network 情報通信研究機構 JGNv6 Network RIBB2 Network Hiroshima City Univ. Robst IPv6 IPv4 IPv6 通信不可 IPv4 カプセル化 IPv4 脱カプセル化 札幌 富山 高知 山梨 PTGATE PTGATE PTGATE PTGATE Multicast IPv6 Multicast IPv6

46. 実証実験Ⅱ - FEC 機能による効果 1.1396 0.8750 1.1020 ジッタ (ms) 0.0033 0.0034 0.0032 パケット損失率 (FEC 後 )[%] 0.4504 0.4504 0.4493 パケット損失率 (FEC 前 )[%] 438 446 429 パケット損失数 (FEC 前 ) 59738 59737 59694 パケット損失数 (FEC 前 ) 山梨 高知 富山

47. 研究のまとめ

48. 研究のまとめ 遠隔コラボレーションシステムの設計と実装 多目的音声伝送システムMRAT (エンドシステム) プロトコル変換ゲートウェイPTGATE (中間システム) 実証実験により遠隔コラボレーションの実践 遠隔合唱，遠隔合奏 遠隔ゼミ 札幌雪祭り広域配信実験

49. 研究のまとめ（続き） 問題点 次世代インフラストラクチャとアプリケーションとのギャップ MRATによる低遅延，ロバスト性の高いシステムの開発 中間システムによりIP層のプロトコルの差異を吸収するシステムの開発 様々な実証実験を行い，ブロードバンドアプリケーションの利用可能性を広げることを実践 イベント的な利用だけではなく定常的な運用 本研究により達成されたこと 問題点 1 解決方法

50. 研究のまとめ（続き） 問題点 ＲＴＰの利用と次世代インフラストラクチャとのギャップ 解決 パケット損失への対応 Reed-Solomon 符号を用いた FEC の実装 再生バッファアルゴリズムの見直し 72ms となる低遅延伝送の達成 問題 ネットワーク仕様やニーズの多様化に因る問題 解決 新たに想定される利用場面の分析，機能設計 中間システムにより広域配送時の問題の解消 これらの問題点を解決することで 遠隔コラボレーションの普及へ貢献 問題点 2 解決方法 問題点 3 解決方法

51. 開発したシステムの適用範囲 MRATの適用範囲 FECにReed-Solomon符号を使用することの限界 ブロック符号の特性上大きなバースト損失に対応しようとすると，演算の処理負荷が大きくなる Chorusモードの利用できる範囲 データの転送速度の限界により合唱できる範囲に制限が生じる 音声に比べ映像伝送のほうが処理遅延が大きくなる傾向にある ＭＲＡＴと他の映像伝送システムを併用すると映像と音声が同期しない

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

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

54. 参考資料

55. Media Specific FECとの比較 RAT には Media Specific FEC （ RFC2198) が実装されている 音声データパケットを複製 次のパケットにくっつけて送信 欠落したパケットがあれば一つ後のパケットにくっついていたものから復元 送信ホスト 受信ホスト Linear-16(PCM) PCMμ-law primary secondary エンコード方式を個々に選択できる

56. Media Specific FECとの比較 RAT に実装されている Media Specific FEC と今回新たに実装した Reed-Solomon FEC との比較を行った ※ secondary encoding に linear-16 を用いた場合 エンコード方式 Linear-16 ， サンプリング周波数 32kHz ， モノラルの場合 パケット損失 20% 下でのそれぞれの FEC の音質の比較 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 [kbps] 2.0 倍 パケット損失 20% の時 MediaSpecificFEC Reed-Solomon(15,8)

57. パリティ符号を用いたFECとの比較 “ 高品質動画像伝送における FEC の性能評価，” 情報処理学会論文誌 , Vol.45, No.1, pp.84-92, 2004.

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).

59. パリティ符号を用いたFECとの比較 1.25 倍の帯域となる RS(15,12) 符号と パリティ (5,4) 符号との比較 パリティ符号 Reed-Solomon 符号 2.0 (2, 1) 1.5 (3, 2) 1.33 (4, 3) 1.36 (15, 11) 1.25 (5, 4) 1.25 (15, 12) 1.2 (6, 5) 1.15 (15, 13) 帯域増加量 [ 倍 ] FEC 帯域増加量 [ 倍 ] FEC 3.44% Parity(5,4) 1.27% RS(15,12) パケット損失 10% の場合

60. DCCP (Datagram Congestion Control Protocol) UDPのNext Generationという位置づけ 現在Internet Draft 実時間通信のために設計されたプロトコル UDP＋輻輳制御 輻輳制御のアルゴリズムを選択可能 CCID2 CCID3

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

62. バースト損失の検討 RS(15,11)符号では，1ブロック中に最大4つまでの連続したパケット損失を回復可能 回復可能はバースト損失は冗長度に依存する 例えば，RS(255,232)符号を用いた場合 1ブロック中に最大23個までバースト損失に対応できる より多くの連続したパケット損失を回復するためには，冗長度を上げる必要がある．冗長度を上げると帯域が増加する バースト耐性と帯域増加率はトレードオフの関係

63. QoS パラメータの例 伝送速度，信号対雑音電力費 (SNR) ，ビット誤り率 ユーザ スループット， PDU 遅延， PDU 揺らぎ， PDU 欠落率 ネットワーク 遅延，因果順序逆転率 PESQ, サンプリングレート，符号化方式 PSNR, フレームレート，解像度，符号化方式 アプリケーション MOS (Mean Opinion Score) ，心理的尺度 ユーザ コンピュータデータ 音声 映像 QoS のレベル

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