1 / 35

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

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

andra
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月20日

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

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

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

  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 RBL (Remaining Buffer Level) stored 最も近距離（ホップ数が少ない場所）にあり, かつ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 ノードのバッファサイズ MICAzと同じ512kB 128kB, 256kBを蓄積用と仮定 node source node sink • データ発生間隔：1 sec（CBR） • MACプロトコル：CSMA/CA 2way • 通信速度電力消費 MICAz Moteに搭載されているCC2420（Zigbeeチップ）を基準 3 CBの評価 （1/3） （Zigbee 802.15.4を参考）

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

  13. 3 CBの評価 – 消費電力推移 （3/3） ＜バッファサイズ変化させたときの消費電力量の評価＞ 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を中心に, 同心円状に蓄積 • 付近まではマルチホップでデータを送信 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） ＜蓄積方式ごとの消費電力量の評価＞ 蓄積用buffer 256kBECBの結果はソースの場所をランダムに設定10回の平均値 • CBに比べてECB1, ECB2の消費電力が大きい • ソースからのマルチホップの分の消費電力が加算されるため • ECB2と比べてECB1の消費電力が大きい • ランデヴーポイントは１箇所しかなく, ホップ数が増えやすいため ECB1: Rendezvous-point 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) 他，研究会3件，総合大会1件発表

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

  22. 補足資料

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

  24. ツリー作成 <ソースノードを根とするツリーの作成> • 閉路をなくし, 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

  25. 経路沿線型のイメージ

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

  27. マルチソースの例 Source1 → Source2の順にCB 蓄積用256kBソースノードで2560kB（ノード10個分）発生したときの例 Source 1 Source 1 Source 2 Source 2 分割無し 分割有り

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

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

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

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

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

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

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

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

More Related