平成 14 年度
修士学位論文P2P アーキテクチャによる多地点間双方向
AV 通信方式に関する検討
A study of multiple points bidirectional AV
communication system based on P2P architecture

1055126

橋本 江里子

指導教員

島村 和典

2003 年 2 月 24 日
高知工科大学大学院 工学研究科 基盤工学専攻
情報システム工学コース

要 旨

P2P アーキテクチャによる多地点間双方向 AV 通信方式に関する検討橋本 江里子IP 網を利用した AV 情報を用いたアプリケー
ションが数多く登場しつつある．本研究では，AV リアルタイムアプリケーションにおいて多地点間双方向の通信方式について検討を行った．従来の多地点間双方向 AV 通信方式では，集中処理形式の AV 合成装置を用い，１度合成装置にユーザの情報が集められ，それぞ
近年のネットワークの高速広帯域化に伴いれのユーザにすべてのユーザの情報を合成変換してから再配信を行っていた．この方法でP2P アーキテクチャへ変更することで問題解決を目指している．既存の技術である DV 転送を評価対象とし，IP網を想定した P2P アーキテクチャ多地点間双方向 AV 通信方式の要求条件や問題点の検討は，遅延や帯域集中等の問題がある．そこで，集中合成による構成を

結果を報告する．
キーワード

P2P,

AV 転送

多地点間双方向AV 通信, マルチキャスト, QoS,{i{,

リアルタイムAbstract

A study of multiple points bidirectional AV communication
system based on P2P architecture
Eriko Hashimoto

Nowadays, network is high speed and wide-band so that the many applications of
AV appeared in the IP network. In this study, multiple points bidirectional communication system was discussed for AV real-time application. The traditional multiple points
bidirectional AV communication are required for the special composition device. Afterall users data are once collected in the synthetic equipment, all users data synthesizes
and these data are delivered to each them. However, this method has problems of delay
and concentrating bandwidth. In order to solve these problems, the multiple points
bidirectional P2P architecture is used. This paper reports the multiple points bidirectional P2P communication of requirement and investigation results as conventionalarchitecture.
P2P, multiple points bidirectional AV communication, multicast, QoS,
real time application, AV transport

key words{ iii {

目次
第1章

1.1
1.2

第2章

はじめに

1

......................................
背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 AV 情報を用いたリアルタイムアプリケーション . . . . . . . . . . .
1.2.2 動画像の品質と情報量の比較 . . . . . . . . . . . . . . . . . . . . .

1
1
2
5

集中合成変換による多地点間双方向 AV 通信

7

目的

DVTS について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 ネットワーク構成 . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 フレームレート調節機能 . . . . . . . . . . . . . . . . . . . . . . .
2.2 他符号化方式との比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 特徴のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 現在の多地点間双方向 AV 通信方式 . . . . . . . . . . . . . . . . . . . . .
2.3.1 システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1

第3章

提案する多地点間双方向 AV 通信方式

3.1

P2P アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 システム構成図 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 両方式の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 符号化復号化処理遅延時間とアクセス回線帯域について . . . . . . . . . .

第4章

4.1

7
7
8
9
10
10
11
11
13

13
13
14
14
17

実験

DVdata 送信における DV トラヒック特性 . . . . . . . . . . . . . . 17
4.1.1 システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
複数

{v{

目次

4.1.2 詳細仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 test packet トラヒック . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 多映像受信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
第5章

5.1

多地点間双方向 AV 通信方式の提案.................................
5.1.1 想定している環境 . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 方式 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 方式 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4 方式 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

第6章

6.1
6.2

新方式の提案

18
19
20
20
20
21
21
22
22
23
23
25

25
25
26
27
27
28
31

まとめ

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
結論

謝辞

33

参考文献

35

{ vi {

目次

付録 A

A.1
A.2
付録 B

37

デジタルビデオフォーマット

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
DV 構成例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
フォーマットピア・ツー・ピアアーキテクチャと通信方式......................
B.1.1 種類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 各アーキテクチャの通信方式について . . . . . . . . . . . . . . . . . . . .
B.2.1 ハイブリッド P2P . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2.2 ピュア P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2.3 グリッド・コンピューティング . . . . . . . . . . . . . . . . . . . .
B.3 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.1

ピア・ツー・ピアアーキテクチャ{ vii {

39

39
39
40
40
41
42
43

図目次
2.1 DVTS ネットワーク系 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 DVTS システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 フレームレート調節機能の詳細について . . . . . . . . . . . . . . . . . . . 9
2.4 集中合成変換型のシステム (4 地点の例) . . . . . . . . . . . . . . . . . . . 11
3.1 P2P 型のシステム（4 地点の例） . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 実験システム環境と端末仕様について . . . . . . . . . . . . . . . . . . . .
4.2 DVdata 送信システムの詳細 . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 DVTS 負荷 30Mbps と 20Mbps . . . . . . . . . . . . . . . . . . . . . . .
4.4 DVTS 負荷 10Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 test packet 送信システムの詳細 . . . . . . . . . . . . . . . . . . . . . . .
4.6 test packet による負荷別パケットロス率 . . . . . . . . . . . . . . . . . . .
4.7 システム構成と端末仕様 (マシンスペック) . . . . . . . . . . . . . . . . . .
4.8 Decode Quality88 × 60 と Decode Quality720 × 480 . . . . . . . . . . .

17
18
19
19
20
21
22
23

5.1 想定しているネットワーク環境 . . . . . . . . . . . . . . . . . . . . . . . .
5.2 方式１ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 方式 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 方式 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25
26
27
28

A.1 DV 規格（映像と音声） . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2 DV の構成例ブロック図 [7] . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.1 ハイブリッド P2P アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . 40
B.2 ピュア P2P アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . 41
{ ix {

図目次

B.3 グリッド・コンピューティングアーキテクチャ . . . . . . . . . . . . . . . . 42

{x{

表目次
1.1 リアルタイムアプリケーション用途別比較 . . . . . . . . . . . . . . . . . .
1.2 DV と他の主な符号化方式の比較 [1] . . . . . . . . . . . . . . . . . . . . .
1.3 動画像の品質と情報量 [1] . . . . . . . . . . . . . . . . . . . . . . . . . . .

2
3
5

2.1 DV と MPEG 比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 符号化復号化処理遅延時間と最大アクセス回線帯域 . . . . . . . . . . . . . 15
3.2 Composition 型と P2P 型での比較 . . . . . . . . . . . . . . . . . . . . . . 15

{ xi {

第1章

はじめに本章で研究の目的と背景について述べる．ネットワークを通じてユーザ同士のコミュニ
ケーションが増加しつつある背景の中で，コミュニケーションを行うことの出来るアプリ
ケーションがどういった用途に使用されれいるのかについて述べる．また，それに伴う動画像の品質や符号化方式についても併せて説明する．

1.1

目的

IP 網を通じてユーザ同士が通信を行った場合，必ずしもリアルタイムでコミュニケーショ
ンを行えているとは限らない．本研究では，多地点間双方向 AV 通信での問題点にに着目し研究を行い，リアルタイム通信の障害に繋がる要因の解決に向けて検討を行う．ここでは，遅延と一極負荷集中問題を重要と考え解決に向けて検討を行うことで，最終的にはリアルタ
イムアプリケーションを用いてユーザ同士がリアルタイムでのコミュニケーションを行うことが出来ることを目標としている．

1.2

背景

研究の背景としてコミュニケーションを行う為に用いられているリアルタイムアプリケー
ションがどのような用途で使われているのかと，その特徴と比較．また一般的にアプリケー
ションで通信を行う場合に用いられている，符号化方式や動画像の品質についても述べる．

{1{

第

1.2.1

1 章 はじめにAV 情報を用いたリアルタイムアプリケーション

本検討でいうリアルタイムアプリケーションとは，ユーザ同士がネットワークを介してなるべく実時間に近い状態で他ユーザと映像や音声などのAV 情報を用いてコミュニケーショ

ンすることを可能としているアプリケーションのことを指している．用途としては以下のよ
うな場合に用いられることが多い．

 テレビ会議
 遠隔授業
 遠隔医療 ネットワークチャット
 ネットワークゲーム 等

1.1 に示した．各項目を地点数，１地点のグループ全体の規模，ユーザの自由度に分けてそれぞれ記載している．
（※ここでの自由度とは, ユーザ個人が自身の意思で通信への参加・脱退を行えるかである.）
それぞれの特性について表

表1.1 リアルタイムアプリケーション用途別比較
用途

地点数

規模

自由度

テレビ会議

多

少

少

遠隔授業

少

多

大

遠隔医療

少

少

大

ネットワークゲーム

多少大ネットワークチャット

多

少

大

テレビ会議は同じ場所に集まることのできないユーザ同士が，共通の環境で通信を行うことが出来る．それぞれの地点ではユーザ数は１人で多地点間を結んでいることが多い．
その為地点数も１地点の規模も少ないがユーザ個人の意思で対象としている自分の参加するグループに参加や脱退を行えるという点では自由度は高いということがいえる．

{2{

1.2 背景
次にネットワークゲーム，チャットについては

IP 網上での不特定多数のユーザが参加自由という点では地点数は膨大になると予想される．１地点の規模はこちらも１人であるといえるがユーザの自由度は高いといえる．このように，リアルタイムに

AV 情報を用いて通信を行うという点ではほぼ同じコミュニケーションにおいても，それぞれの用途によりネット
ワーク全体の規模や使用する回線帯域の条件が変化するということがいえる．
表

1.2 DV と他の主な符号化方式の比較 [1]

方式名

符号化方式

ビットレートDV
MPEG-2MPEG-4MPEG-1
H.261
H.263

DCT
MC + DCT
MC + DCT
MC + DCT
MC + DCT
MC + DCT

30M
10M
5k-4M
1.5M
64k
32k

[bps]

,

一般に使用される画像圧縮方式について方式名 符号化方式，ビットレートについての分類を表1.2 に示す.[1]DV は符号化方式として DCT(discrete cosine transform:離散コサイン変換) が用いられ（※フレームレートの調節によりレート調節可ており，ビットレートは 30Mbps である．
能.）品質はテレビ品質と同等であるといえ，主に高速インターネット．将来の IP 網上での伝送媒体として期待されている．

MPEG-1，2 については符号化方式はどれも MC(motion compensation:動き補償) とDCT によって符号化が行われて，ビットレートはそれぞれ CD ‐ ROM，DVD などそれ
ぞれ大きさが分かれている.
H.261 をもとにした H.263 についても符号化方式は同様であり，品質については TV 電話程度であり伝送媒体については ISDN となっている．
{3{

第1 章 はじめにDV のみが符号化方式について他符号化方式が MC ＋ DCT で行っているところを DV は DCT のみでよい．
DV は映像の中で動いている部分を検出し，その検出部分と１つ前の画面から次の画面を予想するフレーム間での動き補償予測を行っていない．つまり, 他符号化と比較してフ
ここでいえるのが，レームを独立毎で編集することが容易であり，またさまざまな理由により，送信を行った

DVdata が送信先に届いて再生が行われる場合に激しいパケットロスが起きていたとしても，他符号化に比べると映像に与える影響は最小であるということがいえる．[1]{4{1.2 背景1.2.2

動画像の品質と情報量の比較

動画像方式の品質と情報量について表
表

種別

(品質)
VTR 品質
現行テレビ
現行テレビ

HDTV

1.3 で示す．

1.3 動画像の品質と情報量 [1]

画素数

ライン数

360
720
720
1920

240
480
480
1080

フレーム数

[1 秒当り]
30
30
30
30

輝度・色差

4:2:0
4:2:0
4:2:2
4:2:2

情報量

伝送速度

[バイト/時間]
14G
54G
97G
540G

[bps]
30M
120M
216M
1.2G

デジタル動画像は，高さと幅を持ったフレームから構成されており，１フレーム中の画素数，ライン数，及び１秒ごとに伝送されるフレーム数がもとの動画像の持つ情報量となっている．以上表1.3 に示している通り, 動画像の品質と情報量はこのように分類される．[1]

{5{

第2章

集中合成変換による多地点間双方向

AV 通信

AV 通信を行うにあたって，AV 通信リアルタイムアプリ
ケーションとして DVTS を用いて評価を行う．評価基準として使用する DV 転送の条件及本検討では，多地点間双方向

び従来方式と新方式の比較を行い，問題点について述べる．

2.1

DVTS について

DVTS(Digital Video Transport System) においてののネットワーク構成, システム構成,
フレーム調節機能について説明をする.
2.1.1

ネットワーク構成

DVTS においてユーザ同士が通信を行う場合のネットワーク構成について図 2.1 に示す.
まず,DVTS の送信側 (Server application) では DV ビデオで画像が撮影される．撮影された映像は DV 符号化され，送信側の端末に IEEE1394 インタフェースを用いて DV data が入力される．送信側の端末では，DV データを IP パケット化 (RTP/UDP/IP パケット化)
して IP 網上に転送する．受信側 (Client application) の端末では，送信側の端末から IP パ
ケット化された符号化データを受信し，復号化が行われ受信側の端末では送信側から送られ[1] (※表示方法として受信端末で受け取ったデータはディジタルビデ
オデッキ, ビデオカメラなど DV 機器に出力される場合もある．)

た映像が表示される．

{7{

第

2 章 集中合成変換による多地点間双方向 AV 通信
terminal

DV CameraInternet
Server IP UDP RTP
Application
図

2.1.2

DV data

ClientApplication

2.1 DVTS ネットワーク系

システム構成図2.2 DVTS システム構成

DVTS のシステム構成について図 2.2 に示す．
デジタルビデオカメラから撮影された映像は，IEEE1394 インターフェースカードを用いて送信側の PC に入力される．送信側の PC では，DV データを RTP/UDP/IP パケット化してネットワーク上 (インターネット上) へ送信する．データ受信側 PC では，DV 対応のデジタルビデオカメラ及びデジタルビデオデッキによって再生され表示が行われる．

{8{

2.1 DVTS について
2.1.3

フレームレート調節機能

図2.3 フレームレート調節機能の詳細について

DVTS の標準機能としてフレームレート調節機能がある．フレームレートを間引きすることで，DVdata のトラヒック量を削減することができる．図 2.3 に示している 画像間
引きなし はフルレートで 30Mbps． 画像間引き率 12 は 15Mbps． 画像間引き率 13 は
10Mbps．となっている．ここでは，間引きを行う際に音声データはそのままにしておき，
映像データのみを間引いていくことにより，全体のトラヒック量の調整を行っている．これ,

は，映像データに比べて音声データを間引いてしまうと通信中に音声に乱れが生じ 映像の乱れと比較してユーザに不快感を与える可能性が大きいからである．

{9{

第

2.2

2 章 集中合成変換による多地点間双方向 AV 通信

他符号化方式との比較

1.2 において, 一般的な符号化の比較を行った. 本節ではその中でリアルタ
イムアプリケーションとしての用途で使用されている MPEG − 2 に着目し比較した結果を
表 2.1 に示す．また, 本検討で DV を評価した理由について詳しく述べる．
第一章での表

表
比較項目
所要帯域
圧縮率

2.1 DV と MPEG 比較
DV
MPEG
30Mbps1
2〜30Mbps
約 3 分の 1
50 分の 1(最大)

圧縮方式

フレーム内

フレーム内，フレーム間

転送時の帯域変動性

調節可能

画像の動きに応じて変動

MPEG はフレーム間予測を門地板圧縮方法を適用しており，動きの大きい画像を転送し表示を行った場合パケット損失が 1%であっても映像の再生品質劣化が激しい．[1]一方，DV の場合は映像の品質には MPEG に比べて劣化が少ない．IP ネットワークでは
パケットロスを想定せざるを得ないため, DV は MPEG-2 と比較して画質劣化が小さいので，今後の IP 上の AV アプリケーションではより多用されると想定した．よって本研究では DVTS を評価対象にする．
2.2.1

特徴のまとめ以上ここまでの

DVTS の特徴をまとめると以下のようになる

DV は MPEG と比較してフレーム間予測でない為，パケットロスが発生した場合に受信側での再生に響きにくい．

 符号化復号化に専用のハードウェアを必要としない．

{ 10 {

2.3 現在の多地点間双方向 AV 通信方式
 多種類のOS 上で実装されている．(FreeBSD,Windows,Linux,Mac)

2.3

現在の多地点間双方向 AV 通信方式

2.3.1

システム構成DV 転送方式 (DVTS) を用いて集中合成変換を使うと, 多地点間双方向での AV 通信を行う場合，以下に示した図 2.4 のシステムアーキテクチャとなる．
j ^

E

D
RouterRouterD
D

Router

D

A

B

C

D

E

F

G

S E LE C TE DO N -LIN E

j ^switchE

ComposerH

D

NW
RouterE
Distributer

E
E

D

E

E:Encoder
D:Decoderj ^図2.4 集中合成変換型のシステム (4 地点の例)

ここでは，各カメラから入力された画像がEncoder によって符号化が行われる．パケッ

DVdata は指定された送信先へと送信される．しかし相手先に送信される前に DVdata は，先に Decoder によって復号化された後，1 度画像合成装置（図 2.4 参照：
composer）へと送られる．画像合成装置では他地点から送られてきた他のユーザの画像情報と合成が行われる．他の画像と合成がおこなわれたあと，分配装置（図 2.4 参照：
distributer）によって相手先の端末で再び Encoder により符号化され DVdata が送信さ
ト化された

れる．送信者からのデータを受け取ることを希望している全ての受信側では，受け取った

DVdata を Decoder により復号処理を行って画面に表示される．多地点間双方向 AV 通信のように，送信者から送られた画像は図 2.4 で示すように一度専用装置で映像合成が行われ{ 11 {

第る．よって，このシステムの場合の2 章 集中合成変換による多地点間双方向 AV 通信

3 地点からの画像と合成が行われ，自分を含めた 4 枚の画像が一枚の絵となった映像が各地点に送信され表示が行われる．

{ 12 {

第3章

AV 通信

提案する多地点間双方向方式

3.1

P2P アーキテクチャ

3.1.1

システム構成図P2P 型での多地点間双方向 AV 通

本節では，前節の集中合成変換型での問題点をもとに，信方式のアーキテクチャを提案する．この方式では，特定の専用装置に依存せず個々の端末がその機能を担うことにより通信を行うことができる．システム構成図を図

j ^

E

j ^

j ^

D

D

3.1 に示す．

DSD

M edia C onverter
C .1A
_5V
__D __+RXTX

U P LIN K

LIN K

PW R

LIN K

D

D

Router

j ^

j ^

D

D
Routerj ^j ^Router
D

D

j ^

j ^

NW
SD

M edia C onverter
C .1A
_5V
__D __+SD

RouterM edia C onverter
C .1A
_5V
__D __+RXTX

U P LIN K

LIN K

PW R

LIN K

RX
TX

U P LIN K

LIN K

PW R

LIN K

E

E
SD

M edia C onverter
C .1A
_5V
__D __+RXTX

U P LIN K

LIN K

PW R

LIN K

E

D

j ^

図

D

D

j ^

j ^

E:Encoder
D:Decoder

3.1 P2P 型のシステム（4 地点の例）

3.1 に示している P2P アーキテクチャによる多地点間双方向 AV 通信方式ではカメラから入力された DVdata は Encoder によって RTP/UDP/IP パケット化され相手先に送信
図{ 13 {

第される．一地点で入力された一つのこでは3 章 提案する多地点間双方向 AV 通信方式

DVdata は専用装置により DVdata が複数地点分（こ3 地点）に複製され送信される．送信されたパケットは直接相手先に届き表示される．その為，各地点より n 地点分の映像がそれぞれの受信端末に到着する．

両方式の比較

3.2

本節では，前節において述べた従来の多地点間双方向

AV 通信である集中合成変換型と本P2P 型のアーキテクチャについて比較を行った．前節までの検討を整理す
ると，集中合成変換型の場合，送信側から受信者にむけて DVdata を送信した場合，一度専用装置に送られ，画像合成・分配装置（Composer・Distributer）を経由させてからそれぞ
検討で提案する

れ相手の端末に送られていた．
そうすると，後者の,,P2P 型と比較して一度専用装置を通らなくてはならない為に起こる

遅延と 符号化 復号化を多く行わなくてはならない為に起こる遅延の問題が発生する．
また，一度画像合成・分配装置を置いてあるエリアに全ユーザからの上りのみの場合

2倍

トラヒックが集中してしまうということがいえる．よって従来の集中合成変換型の場合だと以下のようなことが言える．

 一箇所にトラヒックが集中しネットワークに負荷が集中する
 一度専用装置を介さないといけない為に遅延が発生する

AV 通信方式を行う
場合アプリケーションにとって重要となる項目をまとめての両者の比較を表 3.2 で行った．
また上で述べた 遅延 と 負荷の一極集中 について評価式をまとめたので下の図 3.1 に以上のことより，リアルタイムアプリケーションでの多人数双方向

示す．

3.3

符号化復号化処理遅延時間とアクセス回線帯域について

n 地点に点在するユーザ間で双方向通信を行う場合，その情報は直接各地点へ配信される．前節の問題点で挙げた遅延と負荷集中の問題について，両者の符号化復号化処理遅延時{ 14 {

3.3 符号化復号化処理遅延時間とアクセス回線帯域について間と最大アクセス回線の評価式の比較を表

3.1 に示す．

なお，ここでの変数はe= 符号化遅延時間 ; = 復号化遅延時間 ; = 通信地点数; = DV 送信に要する帯域;
d

n

a

である．

3.1 符号化復号化処理遅延時間と最大アクセス回線帯域
比較項目
Composition 型 P2P 型
符号化復号化処理遅延時間2( + )+
最大アクセス回線帯域
2( 1)
( 1)
表

e

d

n

e

a

d

n n

a

AV 通信システムを P2P アーキテクチャで構成した系を，表 3.1 に示す．符号化・復号化遅延は 12 になりアクセス系の転送帯域条件は均等となる.
多地点間双方向表

表

3.2 Composition 型と P2P 型での比較
比較項目
Composition 型 P2P 型
遅延

有

無

回線容量

小さい

大きい

スケーラビリティ

無有

映像品質劣化

多い

少ない

アプリケーション自由度

有無3.2 より P2P 型は Composition 型と比べ遅延については直接相手側に送信するだけでよく，理論上 12 の時間で良いということが言える．必要帯域については後節で詳しくふれる．以上をふまえて両システムの比較について表

3.2 にまとめる．

P2P ネットワークを実現するにあたり問題となるのは以下の点である．前節で述べた通り，P2P 型にすることにより遅延が減少することは証明された．しかし帯域については負荷集中は発生しないも(のの，帯域は n n1) () 必要であり 2 に比例して帯域が必要となってくる．よって P2P で

a M bpsnの問題点はネットワークで消費する総帯域の軽減であると言える．

{ 15 {

第4章

実験
本章では実験用ネットワークを構築し，その中で，本研究の問題点に応じて必要と思われる

DVTSのトラヒック特性を調査するために実験を行った．

複数 DVdata 送信における DV トラヒック特性

4.1

同じ回線に

DVdata を 2 つ流すことにより DVdata の送信データの大きさ別で，もう一方のDVdata にパケットロスでどのような影響がでるのかを測定した．実験のシステム構成と端末仕様にについては 4.1.2 システム構成にて示す.
システム構成4.1.1

100Base-TX

7x

8x

9x

1x

2x

3x

10x

11x 12x

7x

8x

9x

4x

5x

1x

2x

3x

10x

11x 12x4x

5xEthernet

Ethernet

Client A
Client B
DVTS Client
IP:192.168.12.13
DVTS Server
GW:192.168.12.133
BSD Router
IP:192.168.11.12
swich
OS:Windows2000 swich
GW:192.168.11.122
OS:Windows2000
C

7 8 9101112

A

12 34 56

A

6x

B

Client C

8x

9x

1x

2x

3x

10x

11x 12x

7x

8x

9x

4x

5x

1x

2x

3x

10x

11x 12x4x

5x

7 8 9101112
12 34 56

A

6x

B

6x

Client D

DVTS Client
IP:192.168.12.14
GW:192.168.12.133
OS:Windows2000

DVTS Server
IP:192.168.11.13
GW:192.168.11.122
OS:Windows2000

図

端末使用は図

7x

C

A

6x

4.1 実験システム環境と端末仕様について

4.1 の通りとなっている．

{ 17 {

第4.1.2

4 章 実験

詳細仕様
100Base-TX
DV data
DVTS Client
IP:192.168.12.13
GW:192.168.12.133
OS:Windows2000
8x

9x

10x

11x 12x

7x

8x

9x

10x

7 8 9101112
A

12 34 56

BSD Router

11x 12x

Ethernet

Ethernet

7x
C

1x

2x

3x

A

4x

5x

6x

1x

2x

3x

B

4x

5x

8x

9x

1x

2x

3x

10x

11x 12x

7x

8x

9x

4x

5x

1x

2x

3x

10x

11x 12x4x

5x

7 8 9101112
A

6x

switch7xC

12 34 56

A

6x

B

6x

switch

DVTS Server
IP:192.168.11.12
GW:192.168.11.122
OS:Windows2000

DV data
DVTS Client
IP:192.168.12.14
GW:192.168.12.133
OS:Windows2000

図DVTS Server
IP:192.168.11.13
GW:192.168.11.122
OS:Windows2000

4.2 DVdata 送信システムの詳細

BSDRouter に接続して，ローカルエリア内での IP を割り当てた．このうち ClientAと B を，ClientC と D にそれぞれ 2 セットの DVdata を送った. こうすることにより, 片方の端末同士でに DVdata でのネットワークへの輻輳状態を作り, もう片方の端末同士で DVdata を送受信することによりパケットロス率について調査を行った.
（※ Client の分類については 4.1.2 での図 4.1 での実験システム環境と同じものとする.）
４台の端末を{ 18 {

4.1 複数 DVdata 送信における DV トラヒック特性
4.1.3

結果

図

4.3 DVTS 負荷 30Mbps と 20Mbps

図

4.4 DVTS 負荷 10Mbps

4.3 と図 4.4 に示した通りである. それぞれの状態において, パケットロス率が一定でない
上に, 負荷をかけた通信の方と, ロス率を見るために流したデータとでは特性がまるで一定でないという結果になった. そして, まったく負荷をかけてない状態で DVdata を送信した場合でもパケットロ
ス率が最高で 5%前後出ているという結果になった.
結果は図{ 19 {

第4.1.4

4 章 実験

考察

DVTS を用いてストリームの大きさを変化させて, もう一方での DVTS のパケットロスを調査した結果, これは DVTS 自身の問題であり, 原因についてはで OS 間での相性の問題が起因している可能性があると考えられる. それ以外の問題では不規則的にパケットロスが発生している.
よって,DVdata 同士で輻輳状態を作り出し,DVdata のパケットロス率をみた場合固定レートで負荷をかけた状態とレートを調節している状態, 両者とも負荷が一定でないということが言える.
この実験では

4.2

test packet トラヒック

4.2.1

システム構成100Base-TX
test packet
DVTS Client
IP:192.168.12.13
GW:192.168.12.133
OS:Windows2000
8x

9x

10x

11x 12x

7x

8x

9x

10x

7 8 9101112
A

12 34 56

BSD Router

11x 12x

Ethernet

Ethernet

7x
C

1x

2x

3x

A

4x

5x

6x

1x

2x

3x

B

4x

5x

8x

9x

1x

2x

3x

10x

11x 12x

7x

8x

9x

4x

5x

1x

2x

3x

10x

11x 12x4x

5x

7 8 9101112
A

6x

swich

7x
C

12 34 56

A

6x

B

swich

6x

DVTS Server
IP:192.168.11.12
GW:192.168.11.122
OS:Windows2000

DV data
DVTS Client
IP:192.168.12.14
GW:192.168.12.133
OS:Windows2000

図DVTS Server
IP:192.168.11.13
GW:192.168.11.122
OS:Windows2000

4.5 test packet 送信システムの詳細

4 台用意し，一対（ClientB から ClientA へ）の PC は UDP のテストパケットを送受信し，もう一対（ClientD から ClientC）の PC で 3 種類の DVTS data （10Mbps,20Mbps,30Mbps）を送受信しパケットロスについて計測を図 4.5 のシステムで行う.
（※ Client の分類については 4.1.2 での図 4.1 での実験システム環境と同じものとする.）
ClientB から ClientA に UDP の test packet を送信する．データサイズを指定してデータの負荷の調節を行ったこの data はシステム内でに DVdata を送信する経路のネットワークに負荷をかける.
UDP の test packet での負荷の大きさは，平均して 9，18，27，36，44，53，62，70，76Mbps を送信した．その間,ClientD から ClientC に向けて DVdata を送信して test packet 負荷による DV
パケットのロス率について測定した．送信した DVdata については 30Mbps，20Mbps，10Mbps で端末を{ 20 {

4.2 test packet トラヒック
ある．

4.2.2

結果

図

4.6 test packet による負荷別パケットロス率

4.6 に 示 す. test packet 負 荷 が 9Mbps の 場 合,DVTS 負 荷 の 3 種 類（10Mbps,20Mbps,30Mbps）と も パ ケ ッ ト ロ ス 率 25%弱 で あ る.
DVTS 負 荷 は 3 種 類（10Mbps,20Mbps,30Mbps）と も パ ケ ッ ト ロ ス 率 は 同 じ で あ り, そ れ は test packet に よ る 負荷を増加させた場合でも同じ事がいえる. 3 種類ともばらつきがあり一定的ではないものの増加の一途をたどっている.
結果について図

4.2.3

考察

,

ここでは リアルタイムアプリケーションがIP 網上で転送された場合, DVdata と同じく,UDP パ

ケットのような実時間性の高いパケットが先にネットワーク上で輻輳状態を起こしていた場合を想定.

,

9Mbps の状態でパケットロスが約 25%も発生した. これは,実験系ネットワーク内において同じ経路に輻輳状態を高めた為であると考えられる. その後負荷を上げていくと同時にパケットロス率も増加していることから, ネットワークの輻輳状態が高ければ高いほどパケットロス率も高くなるということがこの結果よりいえる.
しての実験であった 結果は 負荷かけた{ 21 {

第4 章 実験

多映像受信

4.3,P2P での多地点間双方向 AV 通信の実現の為に, 将来図 3.1 で DVdata を送信する場合,
一つのカメラから入力された DVdata を専用装置を通すことで 3 地点間に送信した. 各エリアの受信端末では 1 地点に端末を 3 台用意して各地の映像を受信するようになっていた. ここでは, その受信端
末が 3 台必要な問題について, DVTS の機能として実装されている PORT を指定して DVdata を受信することで, 現在の 1 台の端末においてどれだけの DV 映像を同時受信できるかを把握することを目的としている. また受信端末の CPU 負荷を計測することで, 将来 P2P において受信端末のコスト
ここではの問題に関係してくると考えている

システム構成

4.3.1

(

)
(
)
図 4.7 に示す. 構成は一台のルータを中心とし,switch を介することで 5 地点に端末を設置した. その

多画面受信におけるシステム構成図 左図参照 とそのシステムにおいての端末仕様 右図参照 を100Base-TX
Client A

7x

8x

9x

1x

2x

3x

10x

11x 12x

7x

8x

9x

4x

5x

1x

2x

3x

10x

11x 12x4x

5xEthernet

Ethernet

Client B
DVTS Server
IP:192.168.10.1
DVTS Server
GW:192.168.10.111
BSD Router
IP:192.168.11.1
swich
OS:Windows2000 swich
GW:192.168.11.122
OS:FreeBSDC

7 8 9101112

A

12 34 56

A

6x

B

Client C

DVTS Server
IP:192.168.10.2
GW:192.168.10.111
OS:FreeBSD

7x

8x

9x

1x

2x

3x

10x

11x 12x

7x

8x

9x

4x

5x

1x

2x

3x

10x

11x 12x4x

5xC

7 8 9101112

A

6x

12 34 56

A

6x

B

Client D

DVTS Client
IP:192.168.12.1
GW:192.168.12.133
OS:Windows2000

図6xClient E

DVTS Server
IP:192.168.11.2
GW:192.168.11.122
OS:FreeBSD

4.7 システム構成と端末仕様 (マシンスペック)

ClientA,B,C,E は DVTSServer として DVdata を送信した. 送信した DVdata は ClientD に
よって受信され,CPU 負荷の計測を行った. 各端末のスペックは上記右図のとおりとなっている. 測定
方法については,DVTS の受信機能である,DecodeQuality を 720 × 480 と 88 × 60 の 2 パターンを計測することで, 一番映像のきれいに表示される条件（720 × 480）とすこし映像が荒く表示される条件（88 × 60）でのデータをとり比較を行った. 結果については次ページ図 4.8 にて示す.

うち{ 22 {

4.3 多映像受信
4.3.2

結果

図

4.8 Decode Quality88 × 60 と Decode Quality720 × 480

4.8 は映像送信端末の増加による受信端末での CPU 負荷率について示したものである. 両図において全端末を DVdata30Mbps,15Mbps,1Mbps に合わせて送信したものである. 左図では DVdata
による負荷が 1Mbps で 4 台からの映像を受信端末１台で受けた場合 CPU 使用率が 80%弱である. 他の 15Mbps と 30Mbps を最大 4 台より同時送信した場合, 最終的には CPU 使用率が 100%近くに達してしまった. 右図においては DecodeQuality が 720 × 480 と高いため, 左図での DecodeQuality88
× 60 よりも多くの CPU パワーを必要とした. 結果としては, 3 種類の DVdata のうち全て 3 台目から CPU 使用率が 100%に至り PC 端末自体はフリーズを起こした.
図

4.3.3

考察

. DecodeQuality88 × 60 の左図の場合, 15Mbps や 30Mbps の DVdataと比較して 1Mbps の場合は, 例えば 5 台めの送信端末を増加し映像を送信したとしても, でもこの結果から予想すると 5 台目も可能である可能性が高い. しかし,1Mbps というのは DVTS での標準送信
1
レート 30Mbps から考えると 30でありほぼ静止画に近い. よってリアルタイムコミュニケーションを行う上では, 不適切であると考えられる. しかし, この実験結果からいえることとして DecodeQualityの品質を下げることで受信する映像（送信台数）を増加させることが可能である. よって, 今後の展望としては多地点間双方向 AV 通信を P2P で行う場合に受信端末の PORT を指定することで１台の端末で多地点間の映像を受信することができる. また将来 PC 端末の処理性能の向上に伴い益々多数の端末からの映像を受信することが可能になっていくと考えられる.
以上の結果より考察を行う{ 23 {

第5章

多地点間双方向AV 通信方式の提案

本検討ではマルチキャストを用いることで問題解決の提案を行う．マルチキャストはパケット転送方式の一つで，複数のユーザが一つのグループに属することで，単一のパケットを送信すると各ポイントとなるルータでパケットが複製され送り手に届けられる．よってネットワークにかかる総負荷を軽減することが出来る

5.1.

新方式の提案,P2P アーキテクチャにおける多地点間双方向 AV 通信において今後の環境を想定し新方式にむけて検討を行ったので報告する.
本節ではここまでの議論を整理し5.1.1

想定している環境
30%

60%
30%

DVTS
Client

30%
30%

DVTS
Server

30%
90%
90%

30%
30%

90%
DVTS
Client
DVTS
Client図

5.1 想定しているネットワーク環境

5.1 想定する. このネットワークは多地点間（4 地点）を結んだ
ネットワークである. それぞれの回線の輻輳度が違っており, 図 5.1 に示したとおりである. 例としネットワークを環境例として図{ 25 {

第5 章 多地点間双方向 AV 通信方式の提案

30%と記してある部分は全体の回線の容量の割合からして 30%輻輳していると考えてもらいたい.
端末 4 台の内訳としては, 図左上にある DVTS Server1 台から他端末 DV Client3 台に向けてマルチキャストで DV packet を送信すると仮定する. その場合の方式について以下に 3 つの方式について提案し検討を行う.
て

5.1.2

方式 1

DVTS
Client
DVTS
Server

DVTS
Clienthigh quality video
middle quality video
low quality video
Router

DVTS
Client図5.2 方式１5.2 の方式について説明する. まず, 送信する映像である DVdata は仮に high quality video,
middle quality video, low quality video の 3 種類用意しているものとする.Data の大きさとしては,高いものから順に 30Mbps,20Mbps,10Mbps としておく.
この方式は, 送信する帯域を全体的に比較して, 一番輻輳しているネットワークに送信する映像の大きさを合わせる. すなわち, この図 5.1 を見ると,DVTS Server から残り 3 台の DVTS Client に向けて DVdata を最短で送信しようとした場合, ネットワークの輻輳状態として一番数値が高いのが図左下の DVTS Client への経路にあたる輻輳状態 90%の帯域がネックになっていると考えられる. この方式の場合, この最大輻輳度 90%に合わせて, 全体に一番小さい容量の映像を送信する. あらかじめ用
意しておいた, 映像 3 種類 (high quality, middle quality, low quality video) のうちの一番フレーム
レートを間引いている状態の DVdata を送信する.
[ポイント]
図 直接送るのでリアルタイム性が高い 一番高い輻輳状態に合わせるので条件によって他ネットワークに余裕を残すことができる{ 26 {

5.1 新方式の提案
5.1.3

方式 2

DVTS
Client
DVTS
Server

DVTS
Clienthigh quality video
middle quality video
low quality video
Router

DVTS
Client図5.3 方式 25.3 の方式について説明する. この方式は, 図 5.1 でのそれぞれの輻輳状態に応じた DVdata を送信する.DVTS Server より送信された Data はマルチキャストルータを経由していく過程においてフレームレートを調節することで大きさを変化させるものとする. このネットワークの場合, 輻輳度
30%の部分には high quaity video を送り, 60%の帯域には middle quality video を送り,90%の部分には low quality video を送ることで, それぞれのネットワークに適応させる.
図[ポイント]
 それぞれの帯域に応じて最大限品質の良い映像を届けることができる
 直接送るのでリアルタイム性が高い

5.1.4

方式 3

,

2 と同じでそれぞれのネットワークの状況に応じて送信される DVdata が輻輳状態に対応したものに調節されるものとしていたが, この方式 3 の場合, 最低ラインの映像品質を指定することでその指定されている品質を下回る条件の帯域の場合は, それ以上の条件のいい経路を探索して相手先に DVdata を送り届けるというものである.
この方式は 方式

{ 27 {

第5 章 多地点間双方向 AV 通信方式の提案

DVTS
Client
DVTS
ServerRouter

DVTS
Clienthigh quality video
middle quality video
low quality video

DVTS
Client図5.4 方式 3[ポイント]

 良い条件の経路を検索し Data が送信される為高品質な映像が届く
 条件によっては経路を選択するためにリアルタイム性に乏しい
まとめ

5.2

,

以上 ３つの方式を提案した,.

DVdata をネットワークの輻輳状態に応じて変化するというものであった. ここで本検討においての前提条件について整理をする. 条件は以下の通りである.
全方式とも ネットワークの状態により送信 リアルタイムによる通信が行える 通信を行っているユーザは通信を行っているグループに参加・脱退は自由に行える,

1, 方式 2 は直接送信するからよいが, 方式 3については, 輻輳状態が込み合っていない状態のネットワークを探索して経路を決定する為, 最短経路
を通る可能性は低く, 本方式には好ましくないといえる.
また, 前章の実験結果より輻輳しているネットワークに DVTS のような大きいデータを送信してしまうと, 高いパケットロスを引き起こしてしまう可能性が高いということが検証によって証明された.
本研究では多人数での多地点間双方向 AV 通信を前提としており, たとえネットワークの輻輳状態に応じた DVdata を送信したとしてもグループに参加している人数が増加することが簡単に予想される.
以上の条件により リアルタイムに注目をすると方式{ 28 {

5.2 まとめ,,
ワークに合わた DVdata を全端末に送信する方式が一番好ましいという結論に至った.

以上のことより ネットワークの輻輳状態を調べ 全体の輻輳度を比較し一番輻輳していないネット{ 29 {

第6章

まとめ

6.1

結論

DV 転送方式における多地点間双方向 AV 通信を集中合成変換型のアーキテクチャから P2P 型に変更を行った場合の遅延と負荷の問題について述べた．マルチキャストを最小配信パス帯域に応じた

DVdata 転送することによりパケットロスの影響を抑えることができる AV 通信方式について検討行
い, マルチキャストを用いて送信レート制御を行いネットワークに適応したレートを送信することでネットワーク負荷を最小限に抑えることの出来る多地点間双方向 AV 通信方式について見通しをつけることが出来るという結論に至った.
6.2

今後の課題

マルチキャスト時の配信パスの帯域をどのように知り，送レートを適応制御するかが重要となってくる．今後はマルチキャストを実装したネットワークを構築し，帯域制御をどのように行うかについて検討が必要である．

{ 31 {

謝辞
本研究を進めるにあたり、終始適切な助言をもって丁寧に指導して下さり，時には厳しく，時には暖かく見守って下さった島村和典教授に深く感謝します。
そして，副査として有益なアドバイスをしていただいた情報システム工学コースの岡田守教授ならびに岩田誠教授にも感謝いたします．
同じく有益な議論をしていただき，実験設備も利用させて下さった，通信・放送機構

高知通信トラヒックリサーチセンターギガビットネットワーク研究開発プロジェクトの加藤寛治研究員，高松希匠
研究員をはじめとするメンバーの皆様にも感謝致します．
同研究室博士２年生である中平拓司さんには本研究の基礎方向性について熱心に相談にのっていただ,.

きました。また 技術的なサポートもしていただきました ここに感謝いたします。
同研究室修士２年生である浦西慶規さんには本研究の方向性ならびに実験データ収集のまとめ方や考察の方法細部にわたる議論，ならびに相談にのっていただきました。ここに感謝いたします。
愛媛大学大学院医学部修士２年である坂田青児さんには研究を行っていく上での相談にのっていただ.

きました この場をお借りして深く感謝いたします.

最後に島村研究室のメンバーの皆様にも感謝いたします{ 33 {.

参考文献[1] 勝野聡，浅見徹，江崎浩， IP バージョン 6 を用いたディジタルビデオ映像の転送 ，電子情報通信学会論文誌，VOL.J85-B，NO8，pp.1323-1330，Aug.2002.
[2] アカミネエクトル，若宮直紀，宮原秀夫， アクティブネットワークにおける輻輳適応型動画像マルチキャスト ，電子情報通信学会進学技法.
[3] 向山繁喜，植野誠史，加藤聰彦，鈴木健二， PIM ‐ SM と BGMP を用いたスケーラブルなマ
ルチキャスト QoS ルーチングプロトコルの提案 ，マルチメディア通信と分散処理，[4] 尾上裕子， QoS に基づくマルチキャスト通信 ，情報処理学会[5] 高橋周平，細谷篤，佐藤文明， 信頼性マルチキャストにおける輻輳制御に関する研究 ，マルチメディア，分散，強調とモバイル（DICOMO）シンポジウム）[6] 久保田幸雄編著,1995, デジタルビデオ読本 , オーム社,171[7] 映像情報メディア学会編,1999, ディジタルメディア規格ガイドブック , オーム社,254[8] W・リチャード・スティーヴンス著, 橘康雄訳, 井上尚司監訳, 訓解 TCP/IP Vol.1 プロトコル
ピアソンエデュケーション,632[9] Philip Miller 著, 苅田幸雄完訳, マスタリング TCP/IP 応用編 オーム社,632[10] (Digital Video)over IP , http://www.sfc.wide.ad.jp/DVTS/ 2003 年 1 月 31 日現在[11] P2P アーキテクチャ http://www.cac.co.jp/softechs/images/st25010 7
2003 年 1 月 31 日
:pdf

現在

{ 35 {

付録 A

デジタルビデオフォーマット

A.1

フォーマット図

A.1 DV 規格（映像と音声）

B.3 に現行 TV 信号を記録する場合の映像と音声部分のフォーマットについて示している.[7] 映
像入力信号は 4.2.2 コンポーネント信号 (アナログ入力時は A/D 変換を行う必要有) であり, 音声信号
入力は CD などと同等のサンプリング周波数 48kHz, 量子化精度 16bit, 2 チャンネルとはじめとする
4 種の形式で記録をすることが可能である.[7]またデジタルビデオの圧縮アルゴリズムについて図 B.3 に示す.
図

{ 37 {付録

A.2

A デジタルビデオフォーマット

DV 構成例

デジタルビデオにおいて

DV フォーマットがどのように構成されているのか説明する.

図

A.2 DV の構成例ブロック図 [7].

以下手順について説明する

入力された信号は輝度と色差でありそれぞれサンプリングが行われる.

4:2:2 信号と呼ばれる.
次に水平方向と垂直方向にそれぞれサブサンプリングが行われる. これにより入力情報量は削減される.
次に所定のルールによりシャッフリングが行われる. シャッフリングをする目的は固定長化の単位であるビデオセグメント内の 5MB に含まれる情報量を均一化するためである.
シャッフリングにより構成された各ビデオセグメント（5MB）はその中の各（8 × 8）ブロックごとに DCT 変換される.
すべてのブロックが DCT 変換されたビデオセグメントはいったんバッファに格納される.
ビデオセグメントは量子化される.
量子化された後は, クラス分けが行われ可変長符号化が行われる.
音声も同じく入力されてから映像フレームとの同期がとられ, シャッフリングが行われる.

サンプリングされた信号はサンプリング周波数の比から{ 38 {

付録 B

ピア・ツー・ピアアーキテクチャと通信方式
本節ではピアツーピアアーキテクチャと通信方式について説明する．

B.1

ピア・ツー・ピアアーキテクチャ(

P2P) のピアとは同等という意味を指す. この言葉のとおり, 同じネットワークで繋がった端末同士が通信を行う場合に同等の能力を持ち, 個々で通信を行うということが可能である状態を指す. 資源を共有するという意味もあり, ネットワーク内の端末同士で忙しい PC の処理を何もしていない PC の資源を割り当てて分散して処理を行うなど, お互いの資源を最大限生かした処理が行えるという特徴も持つ.
ピアツーピア 以下

B.1.1

種類

P2P アーキテクチャは大別すると 3 つの方式に分けられる．
 ハイブリッド P2P
 ピュア P2P
 グリッド・コンピューティング,.

次節より 各アーキテクチャの方式による特徴と動作について説明し考察を行う{ 39 {

付録

B ピア・ツー・ピアアーキテクチャと通信方式

B.2

各アーキテクチャの通信方式について

B.2.1

ハイブリッド P2P

P2P とは，必要に応じて用意したサーバを利用しそれ以外では個々の端末同士のPeer な通信をノード間で行う. 図 B.1 に示したシステムでは, まずネットワーク内に端末が 4 台存在
し 1 台サーバの役割を果たす端末を用意しておく.
ハイブリッド[動作説明]
ClientA はサーバに最初の欲しい情報をもっている端末を探すためにサーバに自分の要求のrequest を出す.
サーバはその要求に応じた端末を探しだし ClientA に responce を返す.
もらった情報に該当する端末と通信を行う.

図

B.1 ハイブリッド P2P アーキテクチャ[考察] この方式の場合中央のサーバに情報を集約し, 個々の端末はそこにアクセスをし欲しい情報についての情報を得ると, その端末と直接 P2P で通信を行うというものである. この場合, サーバが情報を一括で管理を行っている為, そこにアクセスを行う端末の一括での集中管理が行うことができる. しかし, 一括で情報を所有しているため, そこへのアクセスが集中してしまう. 情報でなくインデックス{ 40 {

B.2 各アーキテクチャの通信方式について,

をサーバは所有しているもののサーバがダウンしてしまった場合 個々の端末がどのような情報を所有.

,

P2P アーキテクチャについては障害が起きてサーバにアクセスできなくなると全ての端末が通信することが出来なくなる.

しているかが一切分からなくなってしまう よって ハイブリッド

B.2.2

ピュア P2PP2P アーキテクチャは中心となるサーバを持たず, 全端末が同等の役割を果たす. よって通信も直接ノード間で通信が行われる.
[動作説明]
端末間で情報を探すために, 直接アクセスを行う.
ピュア

図B.2 ピュア P2P アーキテクチャ[考察] この方式では, 特定のサーバを必要とせず端末と端末が同等に通信を行っている. 端末同士が直接通信を行えるので, 例えば必要なファイルを探していた場合に障害が起きたとしても他端末に検索をすぐ切り替えられるので, そういう意味では障害に強いということがいえる. しかし, ハイブリッド
型と違い中央のサーバでどの端末にどういった情報があるのか一切知りえることが出来ないので検索に要する時間は必要であるといえる.

{ 41 {

付録

B.2.3

B ピア・ツー・ピアアーキテクチャと通信方式

グリッド・コンピューティング,,

グリッド・コンピューティングのアーキテクチャの場合は サーバが用意されており そのPC が使用されていない端末にアクセスし自身が行っている膨大な計算を使用されていない端末に処理を分散

,

.

,

させ 仕事を割り振ることができる よって ノード同士は通信しないがサーバからの仕事を使われて.

いない資源を用いて主要な計算を行っている[動作説明],

サーバは現在資源を余している端末を見つけると 自分の,.

Manage を送る.

端末ではその処理の計算が行われ 結果が返される

図

B.3 グリッド・コンピューティングアーキテクチャ[考察] この方式の場合, サーバ自身でおこなっている何らかの計算を現在使用されていない端末, す
なわち資源をあましている端末にその計算をふりあてることで処理時間を早くし最終的に計算結果を

.

/

,

再びサーバに戻すというものである 従来の方式としてあったサーバ クライアント型の逆であり この方式が一般的にも普及すれば現在増加の一途を辿る一般.

とが可能であるといえる{ 42 {

PC を共有することで莫大な利益を得るこB.3 まとめ
B.3

まとめ,P2P アーキテクチャの種類と特徴についてまとめた. ここからは,P2P アーキテクチャの長所と短所. また今後の展望についてまとめる. 全体を見て, 長所としていえるのがスケーラビリティ性の高さである. これは, 個々の端末がネットワークを介して同等のものとして通信を行うことが可能である. よって特定の管理サーバを介さずに直接通信できる P2P 型は大変スケーラビリティ性が高いといえる. 逆に短所として挙げられるのが個々の端末が直接通信をおこなうため, システム全体に一貫性をもたしたセキュリティ等の管理が行えないという点である.
以上のことをふまえて,P2P はこれから益々活発化することが予想される. 現時点で, ファイル交換ソ
フト等でそのアーキテクチャとしての特性が活かされユーザ数が爆発的に増加の一途を辿っている.
その反面, 個々の端末の処理機能を上回ったデータ通信を常時行うことによるハード面での影響が心配である. ネットワークが高速広帯域化が進む中, 映像や音声などの大容量のデータがこのような画期的なアーキテクチャによりやり取りが可能となった今,PC の処理性能または周辺機器への配慮必要であると考えられる.
以上{ 43 {