通信インフラ不能時への適用に向けた高信頼の放送型動画・音声ストリーミ
ング方式
代表研究者

宇津 圭祐

東海大学情報通信学部

講師

1 はじめに災害発生に伴う通信インフラ不能時における情報伝達ついて，地域レベルでマイク・スピーカを用いた音
声放送による避難指示の放送を行うことや，紙に書いて掲示する方法がとられる．この問題としては，すぐには通達できない，情報が聞こえづらい，あるいは確認しにくい，すなわち情報到達の即時性，確実性に問題がある．また，被害状況や緊急情報の放送については，未だラジオや小型テレビに依存している．尚，たとえこれらを持ち合わせていたとしても，情報を入手するにはマスコミの取材を待たなければならない．すなわち被災地域内のローカルの情報を即時配信，入手することは困難である．
上記を踏まえ，インフラ不能地域において，地域内の情報を地域内のユーザ端末に対し，動画や音声によって即時に到達させる方法が必要である．代表研究者らはアドホック通信を活用した高信頼・高効率の放送
型情報共有方式（Broadcast Based Information Sharing System: BBISS）を提案している[1][2]．本方式は，ルーティングプロトコルを用いた旧来のアドホックネットワークとは異なっており，ブロードキャスト通信を用いて情報の配信を行う．[1][2]においては，BBISS はテキストファイル，静止画像等，すなわち数 10～
数 100kByte オーダーの非リアルタイムデータを，高信頼・高効率に配信する方式として提案しており，既存方式と比較して有効であることを示している．
本研究では，この BBISS についてストリーミングを高信頼・高効率で実現する目的に対しても適用し，その有効性を示すことを目標にしている．
既に有効性が示されているテキストファイルや静止画像等のデータは，ダウンロードを完了してから再生する（ダウンロード・アンド・プレイ）メディアであるため，一般的にはダウンロード時間は許容され，リアルタイム性は要求されない．その代わり，受信端末において不到達パケット（パケット損失発生）がある
場合，情報の復元が不可能となるためパケットの到達性が要求される．一方で，本研究が想定しているような音声による被災状況や緊急情報の放送については，リアルタイム性が要求されるため，ストリーミングのアプリケーションで実現する必要がある．尚，インターネットにおけるストリーミングについてはある程度の不到達パケットについては許容されるが，通信インフラ不能時のロッシーなアドホック通信環境における適用になるため，インターネット並に維持するためにパケットの到達性を低下させない工夫が必要である．
このように「リアルタイム性を確保しつつパケットの到達性についても確保する」ということは，既存のアプリケーションをそのまま搭載するだけでは実現できず，BBISS の方式自体ではストリーミング配信を実現することはできない．本研究では，リアルタイム性を確保するストリーミング配信について，パケット結合／分割の機能の導入とパラメータのチューニングによって実現している．また，BBISS 自体が持つ機能により，パケットの到達性についても確保している．そして，ネットワークシミュレーションにより方式の有効性について示している．

2 放送型情報共有方式による音声ストリーミング
以下のような環境を想定している．大規模災害が発生し，被災エリア内においては一般加入電話網および移動体通信網は利用できない．想定するエリアとしては，災害発生後に被災地域に開設される避難所，ある
いは町内規模の広さ（数百メートル～数千メートル四方）を想定する．エリア内に位置するユーザ数としては数百規模であり，スマートフォンあるいはタブレット端末，ラップトップ PC を所持している．端末は有効な IP アドレスやゲートウェイ情報を所有していない．通信には，IEEE802.11 シリーズ無線 LAN を用いたアドホックモードのブロードキャスト通信のみ利用することができる．このような状況下で，エリア内の特定の数ノードから，エリア内のノード全体を対象に，一方向の音声ライブストリーミングを行うことを想定する．本研究ではネットワークを研究対象としており，以下で述べる提案方式は音声コーデックとは独立である．コーデックレベルでの補完処理（PLC: Packet Loss Concealment）については検討の対象外である．
1
電気通信普及財団 研究調査報告書

以下では一般的な音声コーデックである G.711[3]を利用することを想定して述べる．
従来のフラッディング方式による音声ストリーミング方式を用いたパケットの送信について図 1 に示す．
シーケンス番号等の情報（RTP: Real time transfer protocol 等による）が付加された音声パケットは，UDP，IP レイヤを通じて下位レイヤに送られる．受信ノードにおいては，上記とは逆に，音声パケットがもとの音声データに復元される．

Receiving terminals

Sending terminal
Application

Audio packets
including time stamps

Codec

Codec

UDP

UDP

IP
IEEE802.11 WLAN

図1

Application

IP
Broadcast transmission

IEEE802.11 WLAN

従来からのフラッディング方式による音声ストリーミングの実現

2-1 要求条件
以下(i)～(iii)の要求条件を満たす方式について検討する。
（i）コリジョンによる配信品質の劣化を抑制
インターネットを含む一般的なネットワークにおけるリアルタイムストリーミングにおいては，パケット損失はある程度許容される．しかし，アドホック通信環境はロッシーであり，特にストリーミングは高レー
トでパケットが生成されるため，コリジョンによるパケット損失が発生しやすい．[4]によれば，IP 電話について G.711 とコーデックレベルでの補完処理を用いた場合，5.00%のパケットロス率において，ランダムなパケットロス，バースト的なパケットロスのいずれの場合も，MOS（Mean Opinion Score）値[5]は 2 より大きい値となっている．ここで MOS 値の 2 は Poor，3 は Fair となっている．本研究では災害時における避難指示や被害状況について一方向の音声ストリーミングによる配信を想定している．このため，聴き取れる程度であれば品質の劣化は許容できるものとし，上記を参考に，不到達パケット（コリジョンによる損
失や，ノードの移動により届かないパケット）の割合は 5.00%以下であれば想定環境において十分であると考える．また，同様の理由により，数秒程度のバッファリング遅延は許容できるものとする．
以上を踏まえ，不到達パケット率 5.00%以下を目標に，コリジョンの発生を抑制し配信品質の劣化を軽減することが必要と考える．
（ii）冗長なパケットの送受信とオーバヘッドの削減
冗長なパケットの送受信を削減することは，(i)で述べたようなコリジョンの発生について抑制する目的にも有効である．また，ノードの電池残量は有限であるため，電池残量の消費は抑制されるべきであり，冗長なパケットの送受信は削減されることが望まれる．また，同様の理由で，パケット転送の際に生じる UDP
レイヤ以下のオーバヘッドについても削減されるべきである．
（iii）HELLO パケット等のオーバヘッドを発生しない
トラフィック負荷の軽減とパケット送受信数の削減のため，ノードの周辺状況を収集・周知するためのHELLO パケットの送信を行わない．

2
電気通信普及財団 研究調査報告書

BBISS に関して，リアルタイム性の高い音声ストリーミングについて高信頼・高効率に実現できれば，前述のテキストデータ，静止画の配信に加え，これらを 1 つの情報転送プラットフォーム上で実現できる．これにより，災害発生時に伴うインフラ不能時における，被害状況や緊急情報の放送の実現に大きく寄与できるものと考えられる．
2-2 提案方式
要求条件を満たす方式として，BBISS を用いた音声ストリーミング方式について以下に提案する．図 2に概要を示す．1 章でも述べたとおり，BBISS はテキストや静止画像等のダウンロード・アンド・プレイのメディアに適用することを想定しており，数 10～数 100ｋByte オーダーの非リアルタイムデータを配信することを目的としている．しかし，BBISS そのものだけで，音声ストリーミングのように高頻度にパケットが生成されるようなアプリケーションに適用することはできない．この課題を解決するため，送信側でBBISS を用いて配信できるように音声パケットを結合し，これを送受信の単位とし，受信側でもとの音声パケットに分割する機能を設け実現している．
（a）音声パケット結合／分割
ストリーミング送信側においては，シーケンス番号等の情報が付加された音声パケットを，一定時間長で結合する．結合する音声パケット数が多いほど，再生開始までのバッファリング時間が長大化する．結合す
る音声パケット数は，後述（b）の BBISS でパケットの分割を行った際，BBISS パケットのペイロードサ
イズの倍数以上の値である必要があり，ペイロードサイズの倍数に近い値が望ましい．図 2 では 0.5 秒（25個の音声パケット）分を結合している．結合されたデータは BBISS に送られる．
ストリーミング受信側においては，BBISS より受け取った結合データを音声パケットに分割し，再生アプ
リケーションに送る，そして音声として再生される．
（b）BBISS によるパケットの配信
BBISS は UDP，IP の上のレイヤで動作する．動作および特長の詳細については[1]を参照されたい．以下の動作説明における「送信」はすべて MAC レイヤによるブロードキャスト送信を意味している．生成ノード（initiator）が，情報（結合された音声パケット）を BBISS パケットに分割する．分割する数は total_packetの設定値に従う．図 2 は total_packet = 3 の例である．値の設定は(a)で結合する音声パケットの数に依存するが詳細については後述する．そして，一定時間間隔（send_interval）で BBISS パケットを送信する（図3 の Sending ステート）．そして情報生成ノードの電波到達範囲内のノードが受信する（図 3 の Receivingステート）．情報を受信完了したノードは，ランダム時間待機し，周辺ノードで情報の中継を行っているノードを検出し，あらかじめ決められたしきい値（relay_threshold）に達した場合に，自身の中継を中止する（図4 の Relay decision ステート）．尚，relay_threshold に満たなければ，その情報の中継が行われる（図 5 のSending ステート）．ここで図 5 は relay_threshold=2 の例である．このため，図 5 の左下部のノードは周囲の 2 ノードが中継を行っていることを検出でき，relay_threshold に達するため，中継は中止される．以上の動作により，不到達パケットが生じないよう，無線ブロードキャスト通信の冗長性を利用し，補完している．これにもかかわらず，不到達パケットが生じた場合（例えば図 5 の右下のノード），図 6 のように
NACK(Negative Acknowledgments)ベースの再送制御が行われる．再送要求の回数はあらかじめ決められた
しきい値（req_threshold）を上限としている．

3
電気通信普及財団 研究調査報告書

Receiving terminals

Sending terminal
Application

25packets (for 0.5 sec.)

Application

……

Codec

……

Codec

Audio packets including time stamps

Audio packet conjunction

Audio packet disjunction
Conjunct Audio packets

BBISS

BBISS
BBISS packets

total_packets = 3
UDP

UDP

IP

IP
Broadcast transmission
IEEE802.11 WLAN

IEEE802.11 WLAN

図 2 提案方式

Sending

Receiving

Retrans. wait.

Initiator(Sender)broadcast

Relay decision

Receiving

Receiving

Relay decision

Relay decision

Receiving

Receiving
2 packets
unreached

図3

Sending ステートと Receiving ステート

Sending

図4

Relay decision ステートと Receiving ステート
Retrans. send.

Sending
Retrans. wait.

Retrans.
PacketRelay decision

図5

Retrans.Req
PacketReceiving

2 packets
unreached
Relay decision ステートと Sending ステート

Retrans. req.

図 6 再送動作4
電気通信普及財団 研究調査報告書

2-3 シミュレーションによる評価
本章では，ネットワークシミュレータ OPNET[6]を用い，提案方式と既存方式の基本性能の比較を行う．
（１）シミュレーション環境
音声ストリームは G.711 を想定し，音声の再生時間は 30 秒間とする．すなわち 50packet/s であるから
合計 1500 パケット相当である．シミュレーションエリアは 1000m x 600m とする．トラフィック負荷の高い場合と低い場合を想定し Simulation #1 と Simulation #2 を想定する．Simulation #1 においては，エリア内のノード数は 200 ノード，ストリーム生成ノード数 2 ノードとする．Simulation #2 として，エリア内のノード数は 800 ノード，ストリーム生成ノード数は 4 とする．ただし，評価対象となるのはこのうち 1
ノードが生成したストリームについてのみであり，この他のノードが生成したものについては評価の対象外とする．すなわち背景トラフィックの位置付けである．全ノードのうちストリーム生成ノードを除いた 10ノードを観測ノードとし，シミュレーションは 10 トライアル行う．すなわち 100 サンプルによって評価する．ノードの設定値は以下のとおりである．ノードは IEEE802.11b 無線 LAN，データレート 11Mbps，アド ホック モー ドでの 通信が 可能で あり ，電波 到達範 囲は半径 150m ， 初 期位 置はラ ンダ ム．移 動はRandomWayPoint モデルに従い，人間の歩行・走行程度の移動速度である(0.00, 4.00) m/s で移動する．生成されたストリームは，以下の方式によって配信される．まず，既存方式（Existing method）として，Simple
Flooding（SF）[7]，Counter-based scheme[7]，LDCF[8]を用いた場合，そして参考のため，既存方式においてパケットを 5 個ずつ結合／分割を行う場合（Existing method w/ c），そして提案方式であるパケットの結合／分割を導入した BBISS の改良方式である．Counter-based scheme を用いる場合は，中継判断しきい値を 3 に指定した場合（C3），2 に指定した場合（C2）を用いる．LDCF を用いる場合は，パケットを受信したノードの送信キューにパケットが存在していない場合に中継判断しきい値を 2，存在している場合に中継判断しきい値を 1 とする場合（LDCF21）と，そしてパケットが存在していない場合に中継判断しきい値を 3，存在している場合に中継判断しきい値を 2 とする場合（LDCF32）とする．パケットサイズは 200Byte（ペイロード 160Byte＋UDP/IP ヘッダ相当 40Byte），送出間隔は 20ms である．受信したパケットについて中継送信を行うまでの待機時間は(20, 200)ms とする．BBISS を用いる場合は，BBISS パケットのペイロ
ード長を 1480Byte とする．BBISS の設定値は，中継中止のためのノード数しきい値（relay_threshold）
を，[2]の検討によって得られた最適値をもとに 2 とする．BBISS パケットの send_interval は 166ms，情報中継までの待ち時間は(16.6,166)ms とする．受信ノードにおける不到達パケット補完のための再送要求回
数しきい値（req_threshold）については，音声ストリーミングに適用した場合，音声パケットの遅延時間について詳細を調査するため，0，1，3 の 3 通りを比較する．以下に音声パケットの結合数と BBISS パケッ
トのパケット構成数（total_packet）について述べる．音声パケット結合数は，先述のとおり，BBISS パケ
ットのペイロードサイズの倍数以下の値である必要があり（音声パケット結合数*音声パケットサイズ≦
payload_size * total_packet），ペイロードサイズの倍数に近い値が望ましい．ここでは，音声パケット結合数は 25，50，75 の 3 通りとする．結合数が 25 パケット（0.5 秒分）の場合，total_packet = 3 となる．結合数が 50 パケット（1.0 秒分）の場合，total_packet = 6 となる．結合数が 75 パケット（1.5 秒分）の場合，
total packet = 9 となる．これらの値を用いた理由は，受信ノードにおいて BBISS パケットが不到達となった（損失した）場合の影響をもとに考慮し定めている．具体的には，音声パケット結合数が多いほど，受信ノードにおいて BBISS パケットが不到達となった（損失した）場合，音声パケットに復元できず音声が途切れる時間が長時間化することになる．許容できる音声停止時間は，当然ながら聴者や音声の内容によって異なるが，数秒オーダーの途切れとなれば無視できないと仮定し，ここでは 1 秒を目安にそのプラスマイナ
ス 50%の時間となる値を想定している．すなわち，1 つの BBISS パケットが不到達となった場合の音声停止時間は，音声パケット結合数が 25（total_packet = 3）のとき音声停止時間は 0.5 秒，50（total_packet =6）のとき 1 秒，75（total_packet = 9）のとき 1.5 秒となる．そして，BBISS により配信される．尚，BBISS
でパケット分割を行った場合，上記設定値では計算上，ペイロード長を満たさないパケットが生じるが，本シミュレーションではペイロード長である 1480Byte に固定してシミュレーションを行う．これは提案方式において不利な条件である．
以上より，9 通りの設定値による配信をシミュレーションする．尚，以降では BBISS の設定値は，(req_threshold, total_packet)として表記する．例えば，req_threshold = 1, total_packet = 3 の場合，(1,3) の5
電気通信普及財団 研究調査報告書

ように表記する．
（２）評価項目
Voice over IP(VoIP)における評価項目としてはパケット遅延，遅延ゆらぎなどが挙げられる．しかし，本研究では災害時における一方向の音声のライブストリーミングを行うことを想定しているから，数秒程度のバッファリング時間は許容でき，パケットの遅延ゆらぎについてもバッファリングによって解決できると考えられる．上記をふまえ，評価項目は以下(i)～(iii)のとおりである．100 サンプル（10 標本ノードにおける10 トライアル）の平均値を求める．
（i）受信成功パケット率[%]
1 つの生成ノードに着目し，生成されたストリームの音声パケット（1500 パケット）のうち，標本ノード
において受信が成功した音声パケットの割合である．高いほど望ましい．
（ii）受信データ量 / {(i)*100}
標本ノードにおける受信データ量（音声データのみではなく，パケット転送のためのオーバヘッド分を含む）について，受信成功パケット率*100 で除することにより正規化している．値は小さいほど冗長な送受信が少なく望ましい．
(iii)パケットの配信遅延時間[s](i)で対象となった受信成功パケットについて，生成ノードにおいてパケットが生成されてから標本ノードに到達するまでの所要時間を受信パケット数で平均する．値は小さいほど望ましい．
（３）シミュレーション結果
シミュレーション結果を図 7～12 に示す．
(i)受信成功パケット率[%]Simulation #1 について図 7，Simulation #2 について図 8 に示す．
まず，既存方式（Existing method）と Existing method w/ c について比較する．Simulation #1 においては，既存方式と Existing method w/ c の間に大きな差異は見られない．また，Simulation #2 においても，既存方式と Existing method w/ c はいずれも低い値となり，改善していない．すなわち，既存方式に単にパケットの結合を取り入れただけでは受信成功パケット率は改善しないことがわかる．これは，Existing
method w/ c はパケットを結合しない場合と比較して，パケットが 1 個損失した際の影響が大きいためと考えられる．また，BBISS とは異なり不到達パケットの再送による補完が行われないことが理由と考えられる．
次に，既存方式と提案方式について比較すると，Simulation #1，Simulation #2 のいずれも既存方式を用いる場合と比較し高い値となった．既存方式においては，トラフィック負荷がより高い Simulation #2 において，受信成功パケット率の低下が生じていた一方，提案方式では受信成功パケット率の低下を抑制できている．これは，提案方式においては，不到達パケットを補完できたためである．尚，受信成功パケット率が最も高かった設定値は，(3,3)，次に(1,3)であり，それぞれ 95.4%，95.2%であった．これは，要求条件（i）
にて言及した不到達パケット率 5.00%以下を満たす結果である．一方，いずれの既存方式においても不到達
パケット率 5.00%以下を満たさなかった．
(ii)受信データ量 / {(i)*100}
Simulation #1 について図 9，Simulation #2 について図 10 に示す．
まず，既存方式と Existing method w/ c について比較する．Simulation #1 では Existing method w/ c において，既存方式より削減が実現できているように見える．これは(i)受信成功パケット率をそのままに，これはパケット結合によりオーバヘッドが削減できたためと考えられる．一方，Simulation #2 では(i)受信成功パケット率が低下しているために，結果として既存方式と同程度の値となっている．
次に，既存方式と提案方式について比較すると，Simulation #1，#2 のいずれにおいても，提案方式は既存方式よりも小さい値となった．これにより，提案方式は既存方式よりも受信成功パケット率を向上させつ

6
電気通信普及財団 研究調査報告書

つも，冗長なパケットの送受信およびオーバヘッドを削減でき，端末の電池残量を効率的に消費できると考えられる．すなわち要求条件（ii）を満たす．
Simulation #1 においては提案方式の設定値によらず差は微小となった．Simulation #2 においては，(0,3),(1,3), (3,3)において，他の設定値よりも小さい値となった．これは以下のように考えられる．Simulation #2の受信成功パケット率である図 8 において，BBISS 転送時の不到達パケットの再送処理が行われない(0,3)，(0,9)を比較すると，(0,9)の方が低く，すなわち不到達パケットの数が多い．つまり，total_packet = 3 である(0,3), (1,3), (3,3)において，不到達パケットの発生に伴う再送処理の発生が少なかったことが理由と考えら
れる．

80%
60%
40%
20%
0%

betterExisting
Proposed method (BBISS)
methods w/ c
Delivery methods / Parameters

20%
0%

Existing
methods

Existing
Proposed method (BBISS)
methods w/ c
Delivery methods / Parametersx106 1.40
1.20
1.00
0.80
0.60
0.40
0.20
0.00

Receiving data / {(i)*100}

better

0.60
0.40
0.20
0.00

SF
C2
C3
LDCF21LDCF32SFC2C3LDCF21LDCF32
(0,3)
(0,6)
(0,9)
(1,3)
(1,6)
(1,9)
(3,3)
(3,6)
(3,9)

Receiving data / {(i)*100}40%

図 8 シミュレーション結果：受信成功パケット率（Simulation #2）

x106 1.00

Existing
methods

60%

better

図 7 シミュレーション結果：受信成功パケット率（Simulation #1）
0.80

80%

betterSF
C2
C3
LDCF21LDCF32SFC2C3LDCF21LDCF32
(0,3)
(0,6)
(0,9)
(1,3)
(1,6)
(1,9)
(3,3)
(3,6)
(3,9)

Existing
methods

100%

SF
C2
C3
LDCF21LDCF32SFC2C3LDCF21LDCF32
(0,3)
(0,6)
(0,9)
(1,3)
(1,6)
(1,9)
(3,3)
(3,6)
(3,9)

Percentage of receivingpackets +/- SD

100%

SF
C2
C3
LDCF21LDCF32SFC2C3LDCF21LDCF32
(0,3)
(0,6)
(0,9)
(1,3)
(1,6)
(1,9)
(3,3)
(3,6)
(3,9)

Percentage of receivingpackets +/- SD(iii)パケットの配信遅延時間[s]Simulation #1 について図 11，Simulation #2 について図 12 に示す．Simulation #1 については，提案方式はいずれも既存方式および Existing method w/ c よりも大きい値となった．Simulation #2 については，提案方式においては total_packet = 3 である，(0,3)，(1,3)，(3,3)において，既存方式の SF，C2，C3，LDCF32，
Existing method w/c の SF，C2，C3，LDCF32 よりも小さい値となった．提案方式の total_packet = 6 である，(0,6)，(1,6)，(3,6)において既存方式および Existing method w/ c と同等の値，total_packet = 9 である，(0,9)，(1,9)，(3,9)においては，既存方式のいずれよりも大きい値となった．配信遅延時間の観点からは，total_packet = 3 である(0,3)，(1,3)，(3,3)が total_packet =6，9 の場合よりも値が小さく，望ましいと考えられる．

Existing
methods

Existing
Proposed method (BBISS)
methods w/ c
Delivery methods / Parameters

Existing
Proposed method (BBISS)
methods w/ c
Delivery methods / Parameters

図 10 シミュレーション結果：
受信データ量／{(i)*100} (Simulation #2)

図 9 シミュレーション結果：
受信データ量／{(i)*100} (Simulation #1)

7
電気通信普及財団 研究調査報告書

Existingmethods

図 11

12
10
8
6
4
2
0

betterSF
C2
C3
LDCF21LDCF32SFC2C3LDCF21LDCF32
(0,3)
(0,6)
(0,9)
(1,3)
(1,6)
(1,9)
(3,3)
(3,6)
(3,9)

Packet latency +/- SD

betterSF
C2
C3
LDCF21LDCF32SFC2C3LDCF21LDCF32
(0,3)
(0,6)
(0,9)
(1,3)
(1,6)
(1,9)
(3,3)
(3,6)
(3,9)

Packet latency +/- SD

12
10
8
6
4
2
0

Existing
methods

Existing
Proposed method (BBISS)
methods w/ c
Delivery methods / parameters

図 12シミュレーション結果：配信所要時間（Simulation #1）

Existing
Proposed method (BBISS)
methods w/ c
Delivery methods / Parameters

シミュレーション結果：配信所要時間（Simulation #2）

3 まとめ
本研究では，大規模災害の発生に伴うインフラ不能時に，放送型情報共有方式（BBISS）を情報転送に用い高信頼・高効率でストリーミング配信を行う方法について検討した．そして、音声ストリーミングに関して、方式検討とネットワークシミュレーションにより性能評価を行った．シミュレーション結果より，提案
方式は既存方式と比較してより良好な品質で音声を再生でき，さらに音声ストリーミングに求められる最低限のロス率を満足できる見通しを示した．また，冗長なパケットの送受信およびオーバヘッドを削減できる
ことにより，電池残量を効率的に消費できることを示した．さらに，配信方式の最適値について考察を得た．
今後の課題として，本研究でのシミュレーション条件以外の状況による評価，および上位アプリケーションの開発について検討する予定である．また，動画ストリーミングの実現に向けた方式改良およびシミュレー
ション評価を行う予定である．

【参考文献】[1] 宇津圭祐，佐野浩士，石井啓之，“ 通信インフラ不能時に向けた放送型情報共有方式 BBISS の提案”，
電気学会研究会資料通信研究会 CMN-14-001，pp.1-6，2014[2] Sayuri Wada, Hiroshi Ishii, Hiroaki Nishikawa and Keisuke Utsu, “An Optimization Study on
Broadcast Based Information Sharing System (BBISS)”, PDPTA’14, pp.485-489, 2014
[3] ITU-T Recommendation G.711, "Pulse code modulation (PCM) of voice frequencies"[4] J.H. James, Bing Chen, Laurie Garrison, "Implementing VoIP: A Voice Transmission Performance
Progress Report", IEEE Communications Magazine, Vol. 72, Issue. 7, pp.36-41, July 2004
[5] Stylianos Karapantazis, Fotini-Niovi Pavlidou, "VoIP:A comprehensive survey on a promoting
technology", Computer Networks, 53, 2009, pp.2050-2059, Elsevier[6] The network simulator "OPNET", http://www.opnet.com[7] Yu-Chee Tseng, Sze-Yao Ni, Yuh-Shyan Chen, Jang-Pinig-Sheu, "The Broadcast Problem in a
Mobile Ad Hoc Network", Wireless Networks Volume 8, Springer, pp. 153-167, Kluwer Academic
Publishers, 2002
[8] 宇津圭祐，石井啓之，“ アドホックネットワークにおけるストリーミング配信向き負荷感応フラッディング”, 電学論 C, No.8, pp.1367-1378，2010

8
電気通信普及財団 研究調査報告書

〈発
題

表

資

名

放送型情報共有方式を用いた高信頼・高効率の音声ストリーミング配信
A Novel Information Sharing Architecture
ConstructedbyBroadcast
Based
Information Sharing System (BBISS)
An Optimization Study on Broadcast
Based Information Sharing System(BBISS)
Safety Information Sharing Application on
BBISS

料〉
掲載誌・学会名等

電子情報通信学会和文論文誌 B

発表年月2015 年 7 月

the 2014 International Conference on Parallel andDistributed Processing Techniques and Applications(PDPTA’14)
the 2014 International Conference on Parallel andDistributed Processing Techniques and Applications(PDPTA’14)
the 2014 International Conference on Parallel andDistributed Processing Techniques and Applications(PDPTA’14)

2014 年 7 月
2014 年 7 月
2014 年 7 月

9電気通信普及財団 研究調査報告書