230 likes | 322 Views
代理端末を用いる アドホックネットワークプロトコル. 研究報告 2010 ・ 12 ・ 22( 水 ) 7093-0058 横田翔子. 1. 研究背景 (1/2). アドホックネットワークへの指向性アンテナの利用 通信距離の拡大 空間利用効率の向上 指向性 MAC プロトコル DMAC(Directional MAC) [Choudhury, MobiCom02] SWAMP [ 長島 , 高田 , 渡辺 , 信学論 , 2004] 指向性 MAC プロトコルの問題 指向性隠れ端末問題 Deafness 問題. 2. 研究背景 (2/2).
E N D
代理端末を用いるアドホックネットワークプロトコル代理端末を用いるアドホックネットワークプロトコル 研究報告 2010・12・22(水) 7093-0058 横田翔子
1. 研究背景(1/2) • アドホックネットワークへの指向性アンテナの利用 • 通信距離の拡大 • 空間利用効率の向上 • 指向性MACプロトコル • DMAC(Directional MAC) [Choudhury, MobiCom02] • SWAMP[長島, 高田, 渡辺, 信学論, 2004] • 指向性MACプロトコルの問題 • 指向性隠れ端末問題 • Deafness問題
2. 研究背景(2/2) • 指向性MACプロトコル(DMAC)の問題点 • 指向性隠れ端末問題 • ZのビームがXとYの通信を破壊 • 解決策 • BRTS(BackwardRTS),RCTS(RelayedCTS) • [Sekido, Takata, Bandai, Watanabe, GLOBECOM05] • deafness問題 • Zが再送を繰り返す • 解決策 • Circular RTS [Korakis, MobiHoc03] Collision X Y Z X Y Z 赤:送信ビーム 青:受信ビーム 3 3
3.研究目的 • 指向性隠れ端末・deafness問題への対処 • 両方の問題は通信中の端末は他の端末の通信状況がわからないことが原因 通信中の端末の代理端末を立てる あと3分待って! Aさん じゃあ3分後にしよう! Bさん Cさん 両方同時に対処する指向性MACプロトコルを提案 4 4
4. 提案方式(1/4)(指向性隠れ端末問題への対処)4. 提案方式(1/4)(指向性隠れ端末問題への対処) RTS CTS RES BCTS DATA ACK Z X M Y 赤:送信ビーム 青:受信ビーム M Y Z X 代理端末が隠れ端末の送信を待機させることで,隠れ端末問題を回避 • XとYはRTS/CTS交換 • XはRES(REServation)フレームを送信し代理端末としてMを選択 • MはXの方向にBCTSフレームを送信 • BCTS(Backward CTS)を受信したZは、XとYの通信が終わるまで待機 5 5
4. 提案方式(2/4)(Deafness問題への対処) RTS RTS CTS RES DATA RCR ACK Z X M Y X Y M Z 赤:送信ビーム 青:受信ビーム • XとYはRTS/CTS交換 • XはRES(REServation)フレームを送信しMを代理端末として選択 • MはXとY以外の方向に巡回受信 • ZがXに向かって通信を開始 • MはXの代わりにZからのRTSを受信 • MはZにRCR(ReCoveRy)フレームを送信し、XとYの通信終了時間までZに待機 代理端末がdeaf端末の送信を検出し,送信を抑えることで,deafness問題を回避 6 6
4. 提案方式(3/4)(両方同時に対処) D X M Y H RTS CTS RES BCTS DATA RTS RCR ACK • XとYはRTS/CTS交換 • XはRESフレームを送信しMを代理端末として選択 • MはHにBCTSフレームを送信 • MはXとY以外の方向に巡回受信 • ZがXに向かって通信を開始 • MはXの代わりにZからのRTSを受信 • MはZにRCRフレームを送信し、XとYの通信終了時間までZに待機 7
4.提案方式(4/4) • 代理端末の選択方法
5.評価方法について • 理論解析 • 解析モデルの設計 • スループット • 定常状態確率 • Deaf端末の通信成功確率など
Yへパケット送信 X Y M Xの代理端末 Z Zへパケット送信 6.解析モデルの設計(1/6) • 固定トポロジにおける各ノードの状態 • ノードXにおける状態遷移 • ノードYにおける状態遷移 • ノードMにおける状態遷移 • ノードZにおける状態遷移
X Y M Z 6.解析モデルの設計(2/6) • 送信ノードXにおける状態遷移 idle ACK送信 RTS受信 データ発生 RTS_RES_SEND CTS_SEND タイムアウト RTS送信RES送信 CTS送信 CTS_WAIT DATA_WAIT CTS受信 DATA受信 DATA_SEND ACK_SEND タイムアウト DATA送信 ACK_WAIT ACK受信
6.解析モデルの設計(3/6) • 受信ノードYにおける状態遷移 idle RTS受信 X Y CTS_SEND M CTS送信 DATA_WAIT ACK送信 DATA受信 ACK_SEND Z
6.解析モデルの設計(4/6) • deafノードZにおける状態遷移 idle X Y データ発生 RTS_RES_SEND M RTS送信RES送信 タイムアウト タイムアウト CTS_WAIT RCR受信 Z DATA_SEND_WAIT
6.解析モデルの設計(5/6) • 代理ノードMの状態遷移 idle タイムアウト バックオフ X Y RES受信 RTS_WAIT M RCR送信 RTS受信 RCR_SEND Z
6.解析モデルの設計(6/6) ACK_SEND ACK送信 DATA送信 RCR_SEND DATA_WAIT RTS受信 CTS送信 RCR送信 CTS_SEND RTS_WAIT RTS受信 RES受信 idle タイムアウト データ発生 RTS_RES_SEND タイムアウト バックオフ ACK受信 RTS送信RES送信 タイムアウト CTS_WAIT RCR受信 CTS受信 DATA_SEND DATA_SEND_WAIT タイムアウト DATA受信 ACK_WAIT
7. まとめと今後の課題 • まとめ • 指向性隠れ端末問題とdeafness問題を同時に解決する方法を提案 • 代理端末の導入 • deafness問題発生時における固定トポロジでの理論解析 • 解析モデルの設計 • 4つのノードの状態の場合分け • 今後の課題 • 解析モデルをプログラミング • 提案方式が達成可能な性能を評価 • 定常状態確率 • スループット • Deaf端末の通信成功確率
5. 性能評価(1/2) • シミュレーションパラメータ 18 18
5. 性能評価(2/2) • シミュレーショントポロジ 3 2 1 500m 500m 45° 4 • 2-3間のレート大 • ⇒deafness問題が発生 • ⇒RTS再送回数の増加 提案方式はRTS再送回数軽減 • Deafness問題発生時シミュレーション 19
RTS受信 データ発生 DATA受信 ACK送信 タイムアウト DATA送信 7.理論解析 • 一つのノードにおける状態遷移図 次の通信へ 次の通信へ default DATA_RECWAIT RES受信 Back_off DATA_REC タイムアウト RTS_WAIT RTS再送信 CTS_RECWAIT RCR_RECWAIT ACK_SENT RCR送信 RCR受信 RCR_SENT DATA_SENT DATA_SENTWAIT ACK_RECWAIT
RTS受信 通信していない 次の通信へ データ発生 CTS送信 DATA受信 ACK送信 CTS受信 タイムアウト DATA送信 ACK受信 RES受信 default RES_REC RTS_REC Back_off BCTS_SENT CTS_SENT タイムアウト BCTS送信 RTS_SENT RTS_WAIT DATA_RECWAIT RTS送信 RES_SENT RTS再送信 DATA_REC RTS_REC RES送信 RCR送信 CTS_RECWAIT RCR_RECWAIT ACK_SENT RCR_SENT RCR受信 CTS_REC RCR_REC DATA_SENT DATA_SENTWAIT ACK_RECWAIT ACK_REC
S:XへCTS送信 X:データ発生 S:データ発生 X:SからのCTS受信 X:SへRTS送信 S:DへRTS送信 X:SへDATA送信 X:代理端末にRES送信 S:代理端末にRES送信 S:XからのDATA受信 D:SからのRTS受信 S:XへACK送信 D:SへCTS送信 X:タイムアウト S:DへDATA送信 X:SからのACK受信 D:SからのDATA受信 X:SへRTS送信 D:SへACK送信 X:代理端末へRES送信 X:代理端末へRES送信 S:XからのRTS受信 S:DからのACK受信 X:SへRTS送信
YでCollision? M Y Z X