1 / 41

センサネットワークにおける協調型データ蓄積方式 に関する研究

センサネットワークにおける協調型データ蓄積方式 に関する研究. 情報学研究科 2 年　 7083-0040 渡辺研究室　 高田 悠 修士最終発表 2010 年 2 月 22 日. 0 目次. 背景・目的 提案方式 CB CB の評価 提案方式の拡張 ECB ECB の評価 考察 まとめと今後の課題. 1 背景・目的 （ 1/2 ）. センサネットワーク 多数の小型センサノードでイベント観測 ノードはセンシングしたデータをシンクへ送信 ノードのリソースの制約 処理能力 , 通信機能 , バッファサイズ センサノードの省電力化は重要

mitchell-jeremiah
Download Presentation

センサネットワークにおける協調型データ蓄積方式 に関する研究

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. センサネットワークにおける協調型データ蓄積方式に関する研究センサネットワークにおける協調型データ蓄積方式に関する研究 情報学研究科2年　7083-0040 渡辺研究室　高田 悠 修士最終発表 2010年2月22日

  2. 0 目次 • 背景・目的 • 提案方式 CB • CBの評価 • 提案方式の拡張 ECB • ECBの評価 • 考察 • まとめと今後の課題

  3. 1 背景・目的 （1/2） • センサネットワーク • 多数の小型センサノードでイベント観測 • ノードはセンシングしたデータをシンクへ送信 • ノードのリソースの制約 • 処理能力, 通信機能, バッファサイズ • センサノードの省電力化は重要 • 画像、音声などの情報を用いた高度な観測 • 小型で安価なCMOSセンサ、カメラ、マイクロフォンなどの開発 ノード シンク カメラ（レンズ径1mm） 数百万画素

  4. 目的：遅延耐性がある大容量データを扱え, 　　　　かつ消費電力の少ないセンサネットワークの構築 1 背景・目的 （2/2） • データの特徴 • 従来 • 気温, 湿度, 光などの数値データ　→ データ量が小さい • 本研究で対象とする高度センサネットワーク • データ量が多い • イベントの発生時にバースト的に発生 • 遅延に対する制約は緩い • 適用事例 • 動物の生態観測, 海上治安維持, 犯罪捜査, 深海水産資源開発など • 従来のマルチホップ型はデータの中継による消費電力が大きい 例）動物の生態観測 広範囲, イベント発生頻度は低い 観察車両を移動シンクとして利用

  5. 本研究では, 複数のノードでデータを蓄積する • Cooperative Buffering (CB)を提案 • 複数の近隣ノードと協調してデータをバッファ • ノードのハードウェア的制約はそのままに　 シンクの到着まで大容量データを蓄積→ ノードの省電力化と大容量データ蓄積を実現 2 提案方式 CB (1/4) • ノードは, 発生データを自身のバッファに蓄積し, シンクの到着を待つ • ノード単体のバッファではシンクの到着前にデータがあふれる • 関連研究（移動シンクを利用するセンサーネットワーク） • Data Mules[R. Shah, S. Roy, S. Jain, and W. Brunette., IEEE Workshop on Sensor Network Protocols and Applications (SNPA), 2003] • DFT-MSN’s[Y. Wang, H. Wu, F. Lin, and N. Tzeng., IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATION, Vol 26, No.5, pp.809-819, June 2008]

  6. シンクの移動パターン • ランダムに移動 • 全ノードを巡回訪問 • ノードからの依頼で移動 2 提案方式 CB (2/4) Cooperative Buffering (CB) の概要 • 発生データを近隣のノードと協調して蓄積 • 送信すべきデータが残っている・・・ • マルチホップでさらに1ホップ先のノードへ • CBで蓄積したデータをシンクが回収 大容量データ発生ノード （ソースノード） D4 source node D3 D1 D2 D5 D3 D4 D0 vacant node D1 D2 D5 sink generated data

  7. 2 提案方式 CB (3/4) <バッファの使用> • データ蓄積用 (buffer) とデータ転送用 (relay) の2つに分割 • 転送用は2ホップ以上離れた協調ノードへのデータ送信に利用 ＜近隣ノードテーブル (Neighbor Table)＞ • Node_ID • HC （Hop Count） 　　　－　自分の先で0でないRBLをもつノードがいる最低HC • RBL (Remaining Buffer Level) 　　　－　自身からHC先のノードのRBLの合計値 buffer relay stored RBL (Remaining Buffer Level) 最も近距離（ホップ数が少ない場所）にあり, かつRBLが最大のノードへ蓄積

  8. 120 1 0 2 提案方式 CB (4/4) <具体的な動作例> CB開始 → データ送信 → テーブル更新 n7, 50 n8, 60 n6, 40 Node 1, 2, 3の合計 Node S’s Neighbor Table Node 3’s Neighbor Table n5, 20 n1, 30 n2, 40 ns , 20 → 0 n3, 50 n4, 20 蓄積用領域: 100

  9. 2 提案方式 CB (4/4) <具体的な動作例> CB開始 → データ送信 → テーブル更新 n7, 50 n8, 60 n6, 40 Node S’s Neighbor Table Node 3’s Neighbor Table n5, 20 n1, 30 n2, 40 ns , 0 n3, 50 n4, 20 最大RBL0になるまで送信 蓄積用領域: 100

  10. 2 20 2 20 70 1 2 提案方式 CB (4/4) <具体的な動作例> CB開始 → データ送信 → テーブル更新 n7, 50 n8, 60 n6, 40 Node S’s Neighbor Table Node 3’s Neighbor Table n5, 20 n1, 30 n2, 40 ns , 20 n3, 0 n4, 20 互いにテーブル情報交換 蓄積用領域: 100

  11. 評価指標：ノードの消費電力 全ノードの送受信消費電力 シミュレーションパラメータ 評価モデル 10×10の格子配置, ノード間隔：10m 通信距離：16m （8近傍と通信可能） ノードのバッファサイズ MICAzと同じ512kBを仮定 マルチホップ (MH)と比較したCBの優位性 MH： ソースから K ホップでシンクへ送信 CB：CBで蓄積したデータをシンクが1ホップで回収 node source node sink • データ発生間隔：1 sec（CBR） • MACプロトコル：CSMA/CA 2way • 通信速度電力消費 MICAz Moteに搭載されているCC2420（Zigbeeチップ）を基準 3 CBの評価 （1/3） （Zigbee 802.15.4を参考） (K = 1, 2, ..., 5)

  12. 3 CBの評価 （2/3） ＜マルチホップと比較したCBの優位性の評価＞ Improvement = EnergyMulti – EnergyCB 蓄積用buffer 256kB K = 5 K = 4 K ≧ 3 K = 3 K = 2 K = 1 • K = 1では Improvement が負の値をとる • Kが少ないときはマルチホップによるデータ中継が少ないため • K ≧ 3では Improvement が正の値をとる • マルチホップにおけるデータ中継の消費電力がCBを上回るため

  13. 3 CBの評価 （3/3） ＜バッファサイズ変化させたときのCBの消費電力量の評価＞ buffer= 128kB buffer = 256kB • 蓄積用バッファサイズが大きい程低総消費電力 • ノード単体でバッファできるデータ量が大きいため • 発生データ量が大きいほど消費電力の増加も大きい • 協調ノードへデータを送信する際のホップ数が増加するため

  14. 4 提案方式の拡張 ECB（1/3） • 課題 耐遅延でも遅延は短いことが求められる • 許容される伝送遅延の超過 データ回収時間を考慮したCBの検討が必要 • シンクの移動特性に適応した蓄積方式 Extended Cooperative Buffering (ECB) • CB：近傍ノード型（Concentric Type） • ECB1:ランデヴーポイント型（Rendezvous-point Type） • ECB2:経路沿線型（Along-route Type）

  15. 4 提案方式の拡張 ECB（2/3） ECB1:ランデヴーポイント型（Rendezvous-point Type） • rendezvous point直近のノードを中心とし, 通常のCB同様近傍ノードへ蓄積 • 付近まではマルチホップでデータを送信 rendezvous pointシンクが定期的に訪れる場所

  16. 4 提案方式の拡張 ECB（3/3） ECB2:経路沿線型（Along-route Type） • シンクの移動経路沿いのノードに蓄積 • ソースから最小ホップで届く経路付近のノードまでのデータ伝送には通常のマルチホップ sink’s route

  17. 5 性能評価 （1/2） node source node rendezvous-point sink sink’s route • 評価トポロジ ＜データ回収時間の評価＞ ECB2：経路沿線型 ECB1：ランデヴーポイント型 CB：近傍ノード型 ノード間隔：10 mシンクの速度：20 km/h※通信遅延は無視 CBに比べECB1, ECB2の回収時間が短い

  18. 5 性能評価 （2/2） ＜蓄積方式ごとの消費電力量の評価＞ ECB1: Rendezvous-point 蓄積用buffer 256kB • CBに比べてECB1, ECB2の消費電力が大きい • ソースからのマルチホップの分の消費電力が加算されるため • ECB2と比べてECB1の消費電力が大きい • ランデヴーポイントは１箇所しかなく, ホップ数が増えやすいため ECB2: Along-route CB: Concentric

  19. 6 考察 • 定性評価 • 回収時間および消費電力を考慮したセンサネットワーク構築 • アプリケーションやシンクの移動特性に応じた蓄積方式の選択が必要 CB1） Concentric Type, ECB1） Rendezvous-point Type, ECB2） Along-route Type 経路の構成, 長さにより変化　　ソースの位置により変化

  20. 7 まとめと今後の課題 • まとめ • 耐遅延データを扱う協調型データ蓄積方式Cooperative Bufferingを提案, 評価 • シンクまで一定以上の距離がある場合はCBが優位 • バッファサイズが大きい程全体の消費電力は少ない • シンクのデータ回収時間を考慮したCB (ECB)の提案 • データ回収時間, 消費電力の評価 • ECBはデータ回収時間の削減が可能, 一方で消費電力は高い アプリケーションやシンクの移動特性に応じた蓄積方式の選択が重要 • 今後の課題 • 実アプリケーションを想定した回収時間の詳細な評価 • 研究業績 (1) 高田悠，萬代雅希，木谷友哉，渡辺尚：[奨励講演] 移動シンクを用いた協調型データ蓄積方式，電子情報通信学会，ネットワークシステム研究会（NS）, Vol.109, No.228, NS2009-99, pp.127-132 (2009). (2) Takada, Y., Bandai, M., Kitani, T., Watanabe, T.: Cooperative Data Buffering with Mobile Sinks for Wireless Multimedia Sensor Network, Journal of Information Processing Society (JIP), Vol.18 (2010 年3 月掲載予定). 他，研究会3件，総合大会1件発表

  21. ご清聴ありがとうございました

  22. 補足資料

  23. センサネットワークの応用事例 • 防犯・災害予測 － 災害自動監視・警報 • 防犯・セキュリティ － 不正侵入・盗難防止 • 食・農業 － 温室管理, 天候・土壌モニタリング • 環境保全 － 産業廃棄マップ • 医療福祉 － 在宅健康管理チェック・在宅検診 • 交通 － 交通制御, 事故回避 • 構造物管理 － 老朽化監視（橋やビルなど） • 情報家電 － 家電遠隔操作 もともとは戦場にいる敵の監視からスタート

  24. 緊急を要するセンサネットワーク • 災害時の人命救助 • 倒壊した建物へ上空からセンサーばらまき • 生体反応があることを通知 • 在宅医療（発作, 心肺停止などの検知） • 症状, 危険状態を病院へ • 緊急車両の要請 • 犯罪者追跡 • 逃走車両のナンバー, 犯人の顔写真などで犯人特定 • 位置情報, 逃走した方角を関係者に通知 必要最低限な情報を素早く通知することが必要

  25. 緊急を要しないセンサネットワーク 中～長期的な観測への応用分野 • 環境観測 • 大気中の濃度（二酸化炭素, 有害物質等） • 農業観測 • 散布した農薬の濃度 • 葉の健康管理（カメラで葉の状態を定期的に撮影）田中 公祐, 佐藤 祐樹, 諏訪 敬祐, “ワイヤレスセンサネットワークにおける画像伝送技術に関する研究,” 武蔵工業大学 環境情報学部 情報メディアセンタージャーナル 第8号, April 2007 • 動物の生態観測 • 野鳥の生態観測 • 希少動物の撮影

  26. データ量の違い • MTS400（MICAz用センサ基板）のセンサデータ2軸加速度・気圧・光・湿度・温度 • 26 bytes • VGAサイズのフルカラー画像(640×480×24 bit) • 921, 600 bytes 921600 / 26 = 35446.1538 センサデータのおよそ35000倍

  27. 容量について • BSデジタルのフルHDを記録した場合, 単純計算で１分0.5~1G • HD放送で最も記録容量を必要とするのは、BSデジタルなどで採用されている「フルHD」放送だ。具体的には、「解像度：1920×1080」「動画フォーマット：MPEG-2」「音声フォーマット：AAC」「転送レート：最高24Mbps」となっており、2時間録画するために要する容量は約21.6GBとなる。つまり、フルHD放送の番組をそのまま録画する場合、「Blu-ray Disc」ならば片面1層ディスク（25GB）1枚で可能だが、「HD DVD」だと片面2層ディスク（30GB）でないと対応できない。 • 価格.comマガジン特集030-1 フルハイビジョンを満喫できる！次世代レコーダー&大型フラットテレビ • http://kakaku.com/magazine/030/p01.html

  28. なぜツリーか • RBL重複カウントの防止 n8, 60 Node S’s Neighbor Table n6, 0 n5, 0 n1, 0 n2, 0 ns , 0 n3, 0 n4, 0 n9, 70

  29. ツリー作成 <ソースノードを根とするツリーの作成> • 閉路をなくし, RBLの重複カウントを防止 1．ソースノードがネットワーク全体にHC (Hop Count) packetを送信, HC packetを受信したノードはインクリメントして転送 ※HC：ソースノードからのHC 2．各ノードは重複した親ノードのリンクを互いに削除 3．リンクを削除したノード同士は以後データの送受信はしない n7 n8 , 3 , 3 n6 , 2 n5 , 2 n1 , 1 n2 ns , 1 , 0 n3 , 1 n4 , 2

  30. 経路沿線型のイメージ 道路, 山道の中央, もしくは両サイドにあるノードをイメージ

  31. sink’s route n1’s communication range mobile sink mobile sink sink’s route n2’s communication range data flow シンクの移動方式 • ランダム：アルゴリズム自体は楽、データ回収にばらつきがでる • ノード依頼：依頼が単一なら確実、オーバーヘッド追加 • 固定経路：シンクの手間が省ける、ホップ数増加の可能性あり（下図） • 全ノード訪問：確実なデータ回収、 • ノード依頼

  32. 移動シンクとなりうる移動体 (1/2) • 移動における制約が比較的ゆるい移動体（ある程度自由に移動可） • 人 • バイク, 自転車 • 動物（牧牛, 野鳥など） • 移動における制約が厳しい移動体（移動経路がある程度決まりやすい） • バス, 電車, タクシーなどの自動車 • 船 • 飛行機 • 衛星 • その他ロボットなど • 遠隔操作もしくは自動操縦可能な機械 MULE: storage + transreceiver ① ② ③

  33. 移動シンクとなりうる移動体 (2/2) ※移動のしやすさ → 小回りが利くか 移動パターン, 速度様々 → 移動シンクごとに合わせたCBの方法　　　　　　　　　　　　　　　　　　　同心円, 直線, データセンター…

  34. 問題 離れたノードへの送信が必要となり, 省電力性が低下 マルチソースCB (1/2) • 複数のノードが近距離でソースノードとなるときの動作 • S1でCB後, S2でCBをおこなうときの例 s1 , s2,n1 ,n2 ,n3のRBLは0 n5 n2 n6 s2 s1 n3 ソースノード n1 データを持つノード n4 空のノード

  35. 事前に複数の蓄積用領域を確保 　→ 複数データの受け入れが可能 s2 マルチソースCB (2/2) • 解決方法 • バッファの分割 → 蓄積用バッファをm分割 蓄積用バッファ分割数m = 2 の例 蓄積用（ソース2） 蓄積用（ソース1） s1 n5 n2 転送用 s2 s1 n3 ノード単体の蓄積量が減るため必要となる協調ノード数が増加 n1 n4 適切な分割数mの設定が必要

  36. マルチソースCB • N分割以外の検討案 • データ上書き • 記録時刻　新しいデータを優先して保存 • 重要度　取得したデータの価値が高い方を保存ex) 一番対象物がはっきり写った写真 • 削除 • 必要な容量分だけデータを削除 • 一定の時間が経ったら自動で一部のデータを削除 • データ圧縮 ・データの上書きや削除は結果としてデータ損失を招く ・いずれの方法もアプリケーションやハードウェアに依存

  37. バッファ分割の有無 消費電力は同等~若干上だが, シンクのデータ回収のしやすさにはつながるか Source1 → Source2の順にCB 蓄積用256kBソースノードで2560kB（ノード10個分）発生したときの例 Source 1 Source 1 Source 2 Source 2 分割無し 分割有り

  38. 5.2 性能評価 (3/3) ２つのソースノードで同じ大きさのデータが発生 • 蓄積用バッファを2分割した方が消費電力が大きい • 必要となる協調ノード数が倍となり, 遠くのノードと協調する必要がある →単純なバッファ分割はネットワーク全体の消費電力の増大につながる ソース１ ソース2

  39. Total Battery Cost ()の算出(1/3) • 　　　の定義: 発生データを※シンクに届けるまでの総消費電力（ソースノードから最大hホップまでのノードと協調） • ①～③の和で, 送受信消費電力は送信するデータ数に比例 • ①近隣ノードへの送信消費電力 • ②シンクへの送信消費電力（訪れたシンクに対して1hopで送信） • ③ノードの受信消費電力（近隣ノードのoverhearing含む）また, ホップ数が近いノードから順にバッファしていくものとする • TBCで使用するパラメータ • RX: 受信消費電流 • TX: 送信消費電流 • h: ソースノードからのホップ数 • C: ノードのバッファサイズ（バッファ1でデータ1つを蓄積可能） • D: 発生データ数 • N: 近隣ノード数 ※シンクの移動コストは含んでいない

  40. ①近隣ノードへの送信消費電力 • ②シンクへの送信消費電力 • ③ノードの受信消費電力（overhearing含む） Total Battery Cost ()の算出(2/3)

  41. Total Battery Cost ()の算出(3/3) ・・・

More Related