 メイン Statistics: Understanding Your Simulation Results
アプリケーション層における送信から受信までの経過時間について | 投稿するにはまず登録を |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | スレッド |
|---|---|
| karin | 投稿日時: 2011/10/4 14:53 |
新米   登録日: 2011/10/4 居住地: 投稿: 8 |
アプリケーション層における送信から受信までの経過時間について Qualnet4.0を使用しています．
アプリケーション層において自身でとったメッセージ送受信のログを見たところ，送信から受信までの時間が極端に長くなる場合があります． アプリケーション層のみをコーディングしています． また，IEEE802.11を使用しており，伝送速度は11Mbps，通信半径は100m程度の送信電力に設定しています． 評価環境としては，1000m×1000mの領域に250台の端末が0.5〜1.0m/sの速度でランダムウェイポイントで移動している環境です． この環境において，5秒間に50台の端末がそれぞれ30バイト程度のメッセージをUDPを用いて隣接端末にブロードキャストした場合，送信から受信までの経過時間が極端に長くなる現象が起こる場合があります． 通常ですと，送信から0.01秒前後で受信しているのですが，30秒以上のタイムラグが発生します． この30秒の間，メッセージの新規送信は行われていません． この現象についてなにか情報をお持ちの方がおられましたら，その解決方法あるいは原因の所在について教えていただけないでしょうか？ よろしくお願いいたします． |
| nepia | 投稿日時: 2011/10/5 10:11 |
新米 登録日: 2011/9/26 居住地: 投稿: 3 |
Re: アプリケーション層における送信から受信までの経過時間について 802.11上でのUDPのブロードキャストということなのでどのレイヤーでも再送は行われないはずだと思うので30秒のタイムラグが発生するのは何か変ですよね。
んー，原因はすぐにはわかりませんが， 送信ノードにおける各レイヤーでのパケットの送信時刻と 受信ノードにおける各レイヤーでのパケットの受信時刻の デバッグプリントを追加しシミュレーションを再実行し，どのタイミングでタイムラグが発生しているかを調査してみてはいかがでしょうか。 あるいはシナリオを添付してもらうと他の原因について調査できるかもしれません。 |
| ipoten | 投稿日時: 2011/10/5 18:57 |
一人前  登録日: 2005/7/12 居住地: 投稿: 102 |
Re: アプリケーション層における送信から受信までの経過時間について こんにちは (ここへの投稿は久々
 )QualNetで30秒無通信といって、すぐに思い出すのが Switching Hub の STP (Spanning tree protocol) の学習期間です。 たしかデフォルトの設定で Forwarding状態に移行するのにシミュレーション開始から30秒くらい必要だったはずです。 あとはルーティングとかですかね。 トポロジとか、802.11以外のプロトコル設定はどのようになっているでしょうか。 ソースコード改修されているということなので再現は難しいのかもしれませんが、 nepiaさんの云われるように差し支えのない範囲でシナリオ添付されるとどなたかが見て勘所を教えてくれるのではないかと思います。 ちなみに、改修前のQualNetで同様の現象は発生しますか？ |
| karin | 投稿日時: 2011/10/14 19:44 |
新米 登録日: 2011/10/4 居住地: 投稿: 8 |
Re: アプリケーション層における送信から受信までの経過時間について nepiaさん，ipotenさん，返信ありがとうございます．
返信が遅くなってしまいすみません． その後，トレーサーを利用して各レイヤごとの挙動をトレースしてみたところ，ネットワーク層でENQUEUEが多発していることがわかりました． 現在の挙動は，5秒間に50台の端末がそれぞれ30バイト程度のメッセージをUDPを用いてAODVでユニキャストしているときに起こります． ＃ブロードキャストではなく，ユニキャストでした． ユニキャストの場合，ネットワーク層が宛先のIPアドレスを取得するためのメッセージをまずブロードキャストをしているようなのですが，このメッセージに対する返信がない時に，延々とブロードキャストして，その結果，さらにMAC層がこむのか，状況が悪化してしまっているようなのです． １つ目のメッセージはENQUEUE後，すぐにDEQUEUEされるのですが，その後のメッセージについては，DEQUEUEのタイミングにかなりのばらつきがあります． ログのENQUEUE数を見てみると，1500回にも及びます． 隣接端末は10台程度です． 改修前のQualNetでの確認は，まだできていないです． あと，すみませんが，シナリオとは何をさしてるのかわからないので，教えてください．  よろしくお願いします． |
| nepia | 投稿日時: 2011/10/14 21:49 |
新米 登録日: 2011/9/26 居住地: 投稿: 3 |
Re: アプリケーション層における送信から受信までの経過時間について 何が問題なのかを再確認させていただくと、最初の投稿にあるように、送信から受信までに30秒以上要することがある、というのが問題なんですよね？
いただいた情報から推測すると、(1) 宛先までの経路がない、(2) 無線区間でパケットがロスしている、の2つの可能性があるんじゃないかなーと思いました。AODVの詳細な動作にあまり詳しくないので、的外してたらごめんなさい。 (1)に関しては、UDPでAODVでユニキャストということなので送信元と宛先、その他の端末の位置関係によってはその可能性もあるんじゃないかと思いました。ランダムウェイポイントで端末が動いているうちにAODVが経路を見つけてパケットが送信される、と。まぁ評価環境を見るとある程度端末が密集していそうなので可能性は低そうですが。 (2)に関しては、MAC層、物理層でのパケットロスを確認してみてはどうでしょうか？1台あたりのパケットの送信頻度がわかりませんが、ENQUEUE数が1500回とそれなりの数のパケットを投げようとしているようですし、パケットロスが多発している可能性もあるような気がします。 |
| chackn | 投稿日時: 2011/10/14 22:32 |
常連  登録日: 2005/5/13 居住地: Kanagawa, Japan 投稿: 61 |
Re: アプリケーション層における送信から受信までの経過時間について こんにちは。
私も昔、実機でAODVを動かした時に、karinさんと同じような経験をしました。 引用： 現在の挙動は，5秒間に50台の端末がそれぞれ30バイト程度のメッセージをUDPを用いてAODVでユニキャストしているときに起こります． ユニキャストの場合、MAC層で再送が多発します。データだけでなく、AODVの制御メッセージ(RREPなどユニキャストのもの)も再送されます。 引用： ユニキャストの場合，ネットワーク層が宛先のIPアドレスを取得するためのメッセージをまずブロードキャストをしているようなのですが，このメッセージに対する返信がない時に，延々とブロードキャストして，その結果，さらにMAC層がこむのか，状況が悪化してしまっているようなのです． 「MAC層が混む」わけでないと思います。ブロードキャストしているのはRoute Request(RREQ)ですね。これもRoute Reply(RREP)が返って来ないと数十ms程度の間隔でなんども再送されます。最初は短いホップ数から始めて再送の度にホップ数を増やしながら再送されます。再送間隔もホップ数に応じて長くなります。 この間、RREPが返ってくるまでデータパケットはキューに入ったままとなるので、リンク品質が悪い状況では、後から後からデータパケットが到着してキューはどんどん長くなります。 このようにして、後から到着したデータパケットほど長時間キューで待たされることになります。 結論ですが、ノード間の距離が長かったりしてリンク品質が悪い状況では、データパケットの転送に30秒以上かかることも十分にありえると思いますよ。ノード間隔を十分に短くしたとしても、AODVはリンク品質を考慮せずホップ数の短い経路(つまりノード間の平均距離の長い経路)をわざわざ選びますから、状況が改善されないことも十分に考えられます。 いろいろと試してみてください。 |
| karin | 投稿日時: 2011/10/15 11:50 |
新米 登録日: 2011/10/4 居住地: 投稿: 8 |
Re: アプリケーション層における送信から受信までの経過時間について 返信ありがとうございます！
実機でも，やはりそのようなことが起こるのですね．納得です． 現在の問題としては，今のシミュレーションだと送信から受信までに30秒以上要することがあるけれども，できればそれを解決したいというものです． ルーティングは，自身のプロトコル内（アプリケーション層）で木構造を把握してマルチホップで行なっていて，現在問題となっているユニキャストは隣接端末に宛先の端末がいるような状況のはずなのです．そのため，もし，隣接端末に宛先がいなければ，その通信は失敗という形でよく，AODVの制御メッセージで遅延が起こってしまうのは，避けたいんです． 制御メッセージを再送し続けないようにする設定方法とかあるのでしょうか？ 他の解決法としては，送信自体はブロードキャストにして，アプリケーション層で宛先のもののみが処理を行うというようにすれば解決するのではないかと思っているのですが，何か他によい解決策がありましたら，教えてください． |
| chackn | 投稿日時: 2011/10/16 7:21 |
常連 登録日: 2005/5/13 居住地: Kanagawa, Japan 投稿: 61 |
Re: アプリケーション層における送信から受信までの経過時間について karinさん
引用： ルーティングは，自身のプロトコル内（アプリケーション層）で木構造を把握してマルチホップで行なっていて，現在問題となっているユニキャストは隣接端末に宛先の端末がいるような状況のはずなのです．そのため，もし，隣接端末に宛先がいなければ，その通信は失敗という形でよく，AODVの制御メッセージで遅延が起こってしまうのは，避けたいんです． AODVのパラメータをいじって再送しないようにするか、あるいは再送回数を少なくしてやればいいような気がします。AODVのRFC3561によると、以下のようなパラメータがあるみたいです。 これらの中で関係ありそうなのは以下のパラメータでしょうか。 それぞれの意味についてはRFCをお読みください。AODVはTTLを小さな値(TTL_START)から初めて失敗したらTTLを増やしながらリングサーチをしています。その仕組みをよく理解した上で上記パラメータを変更してみてください。 以下の解説は参考になるかもしれません。 http://internet.watch.impress.co.jp/www/column/wp2p/wp2p07.htm |
| karin | 投稿日時: 2011/10/17 18:09 |
新米 登録日: 2011/10/4 居住地: 投稿: 8 |
Re: アプリケーション層における送信から受信までの経過時間について Chacknさん，返信ありがとうございます！
おっしゃるとおり，AODVのRREQが原因だったようで，パラメータTTL_THRESHOULDを１に変更してみたところ，問題の遅延をなくすことができました． これを機に，下位層についてもしっかり勉強しようと思います． 本当にいろいろとありがとうございました． |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |
