メイン Scenario Setup & Configuration 故意に輻輳ノードを作り、そのノードを削除して別経路を構築した時の効果を見てみたい。 | 投稿するにはまず登録を |
題名 | 投稿者 | 日時 |
---|---|---|
» 故意に輻輳ノードを作り、そのノードを削除して別経路を構築した時の効果を見てみたい。 | umigame24 | 2011/6/24 16:05 |
Re: 故意に輻輳ノードを作り、そのノードを削除して別経路を構築した時の効果を見てみたい。 | ino | 2011/6/24 17:40 |
フラット表示 | 前のトピック | 次のトピック |
投稿者 | スレッド |
---|---|
umigame24 | 投稿日時: 2011/6/24 16:05 |
新米 登録日: 2011/4/29 居住地: 投稿: 3 |
故意に輻輳ノードを作り、そのノードを削除して別経路を構築した時の効果を見てみたい。 QualNetに最近触れ始めた者です。
以後よろしくお願いします。 輻輳ノードとその近隣のノード(さらし端末問題を意識)を削除し、輻輳ノードを避けるような経路を構築した時の結果を見て、別経路(以後迂回経路)と元の経路での結果の違いを確認し、迂回経路を構築することで得られる効果を実際に見るのを目的としています。 例えば、うまく迂回経路が構成できたのなら、アプリケーション層の結果でTotal Packets Recievedが増えるのではないか?そういった点で迂回経路を構築する意味合いとその上での問題点などを実際にシミュレーション上で確認したいと思っています。 使用しているプロトコルはOLSR INRIAです。 7×7のDeviceをGridで設置し、中央に位置するDevice25を故意に輻輳させるために、Device25を横切るようにCBRを送信元から宛先までGUI上で張っています。GUI上でCBRの矢印は中央のDevice25を横切るように設置されているわけですが、実際に全ての通信がDevice25を中継端末として選んでいるわけではないと思います(Run中に視覚的に確認できるトラフィックの流れから)。 Device25で輻輳が若干起こるものの、それ以外のノードでの輻輳が目立ってしまいます。 理想的な結果としては、各CBR通信が中央端末のDevice25を中継端末として選択し、主にDevice25だけで輻輳が発生するような状況を作りだし、Device25とその近隣ノードをGUI上で削除し迂回経路を構築した場合、よりよい結果を得るということを望んでいます。 今現在では輻輳の判定を ・ネットワーク層のPeak Queue Size(Byte)の最大は150000であり、この限界に達している。 ・ネットワーク層のTotal Packets Droppedでパケット落ちが発生している 以上の条件をDevice25が満たしているかどうかをチェックしています。 結果を見たところ、Device25で輻輳条件を満たしてくれましたが、他のノードでの輻輳も目だってしまい、Device25と近隣のノードを削除しても望んだ結果が得られそうもありません。 最初は送信端末から通信させる量が多すぎて、送信端末でパケット落ちが発生してしまうという状況に陥りましたが、IntervalやItem to send,物理層での送信電力などを調整することでその点は解決できました。 Device25以外でパケット落ちが発生しているノードを削除したりなど、なるべくDevice25以外のノードでは輻輳が発生がしないように、端末を少しずつ削除してみるなどもしてみましたが、中々思い通りにはいかず、Device25のパケット落ちよりも、その周辺でのパケット落ちが目立ってしまいます。 Device25だけにトラフィックを集中させるにはどうすればよいでしょうか? ソースプログラムをいじって、中継端末を故意に選択していくという方法がが浮かび上がりますが、QualNet上でソースプログラムはまだ触れたことはなく、どのソースプログラムのどの部分をいじればよいか、どんなソースプログラムを追加すればよいかなど、まったく検討もつきません。 色々と説明が長くなってしまいましたが、ここまで見てくださった方ありがとうございました。 以下に7×7で設置したときのデータを載せておきますので、アドバイスできる方がいましたらよろしくお願いします。 7_7_fukusou.zip |
フラット表示 | 前のトピック | 次のトピック |