802.11aを用いて二つのノード間の通信距離を大きくしながら受信側でのスループットを測定する基礎的なシミュレーションを行っています。
通信距離が大きくなるにつれて、徐々にスループットも低下すると予想をしていたのですが、
100mを超えたあたりでスループットが急激に落ちてしまいます。
PROPAGATION-PATHLOSS-MODELなどを変更してみたのですが、あまり変化がありません。
(他の設定についてはデフォルトの値です)
他に徐々にスループットを変化させるモデルはありますか？？
ご存じのかたいらっしゃいましたら、宜しくお願いします。

スループットが急激に落ちる理由はおそらく、SINRの低下に伴ってBERが増加し、パケットエラーが急激に増えたためだと思います。
そのような場合、変調方式や符号化率を段階的に変化させてやれば、急激にスループットが低下することを防ぐことができます。
以下のパラメータが設定されているかどうか確認してみてください。

PHY802.11-AUTO-RATE-FALLBACK YES

もしNOになっていたら、YESにして試してみてください。

シナリオの部品を添付します。

files.zip

このシナリオ部品を使って、いろいろな組み合わせでチャレンジしてみて下さい。
比較的単純なルールでパラメタが設定してあるので、.statファイルを加工して、
距離別スループットを取り出すことは難しくないと思います。

添付したグラフは、乱数SEEDを変更して100回実行した結果を
重ねたものになります。250m前後が一番ばらついていますね。

range.PNG

準備段階として、まず./bin/radio_range 置きましょう。

デフォルトの 802.11a 設定だと以下の出力になります。
PHY802.11a-TX-POWER や PHY802.11a-RX-SENSITIVITY の設定が
一部で同じ値になっているためです。

radio range: 424.264m, for 802.11a data rate 6.0 Mbps
radio range: 424.264m, for 802.11a data rate 9.0 Mbps
radio range: 356.973m, for 802.11a data rate 12.0 Mbps
radio range: 351.265m, for 802.11a data rate 18.0 Mbps
radio range: 252.717m, for 802.11a data rate 24.0 Mbps
radio range: 230.850m, for 802.11a data rate 36.0 Mbps
radio range: 79.577m, for 802.11a data rate 48.0 Mbps
radio range: 79.577m, for 802.11a data rate 54.0 Mbps

これでもかまわないのですが、ちょっと数値をさわって、
以下の出力になるようにしました。
同一bpsで同じ距離だとなんとなく気持ち悪いので。6.0Mbps、
9.0Mbpsと、48.0Mbps、54.0Mbpsを微妙に変更しています。

radio range: 452.669m, for 802.11a data rate 6.0 Mbps
radio range: 418.161m, for 802.11a data rate 9.0 Mbps
radio range: 386.286m, for 802.11a data rate 12.0 Mbps
radio range: 329.635m, for 802.11a data rate 18.0 Mbps
radio range: 281.292m, for 802.11a data rate 24.0 Mbps
radio range: 185.498m, for 802.11a data rate 36.0 Mbps
radio range: 98.364m, for 802.11a data rate 48.0 Mbps
radio range: 71.630m, for 802.11a data rate 54.0 Mbps

なお、添付したシナリオ部品のrange.appの具体的なパケットサイズ、パケット数、
送信間隔は確認内容に応じて再定義する必要があります。

下記ファイルを使うと便利であることの背景ですが、
10m間隔でNodeを150個分固定配置してもかまいません。
しかし、
1Hop内に大量のNodeがあると、それだけで不必要なトラヒックが発生することがあります。
また、
ルーティングやIPアドレスなどの設定がややこしくなります。
Staticルーティングでよければ、*.routes-static に

1 N8-192.0.0.0 192.0.0.2
2 N8-192.0.0.0 192.0.0.1

と書いておけば定義も簡単です。

シナリオも15200秒=約4時間13分の時間ですが、シミュレーションはすぐ終わります。

ファイル1
range.nodes Node1とNode2が定義されています。
Node1 x座標0m、y座標750m で固定。
Node2 は以下の規則で移動します。
移動は秒速1mで+x方向に移動。10秒移動、90秒静止、を繰り返す。

したがって、
Node2は100秒目にx座標10m、200秒目にx座標20m、...
(t*100)秒目には、(t*10)mのx座標になります。
となります。

ファイル2
range.app CBRの定義です。150個のCBR定義してあります。
毎50秒目に送信開始、毎60秒目で送信停止が定義されています。
(t*100)+50 秒目送信開始、(t*100)+60 秒目送信停止。

これを組み込んだシナリオを、SIMULATION-TIME 15200S だけ動かすと、
*.statにCBR ServerとCBR Clientの出力が沢山出ます。

CBRのstatでは[1024]とか[1025]などの番号が出力されますが、
上記のappを使えば連番で[1024]から[1173]になります。
この番号をpとすると、先ほどのtとの関連は次のようになります。
p = t + 1023

これらの関係から、
たとえばNode間が550mの場合の情報は、
550m = t*10m
t = 55
p = 55 + 1023 = 1078
となるので、

シナリオ時間は、5500秒目から5590秒目までNode2がx座標550mに停止。
CBRは[1078]、の番号で出力されている。

ことになります。

chacknさん、hiroさん

AUTO-RATE-FALLBACKをYESにしたところ、改善できました。
初歩的な質問に親切に答えていただきありがとうございました。

度々質問させてください。
上述と同様のシミュレーションを802.16を用いて行なおうと思っています。

そこで
/QUALNET_HOME/scenarios/advanced_wireless/802.16/multi-rates

にあるmulti-rates.appのみCBRからFTP/GENERICに変更してシミュレーションを行いました。

CBRの場合では確かに距離毎にスループットが設定されているのですが、

FTP/GENERICの場合、通信可能距離手前までスループットが変化しません。

FTPを用いる場合は何か他に設定する必要があるのでしょうか？

おわかりになる方、宜しくお願いします。

具体的にどのように.appを記述したのががわからないので、あくまでも憶測ですが。
CBRで期待した挙動を示し、FTP/GENERICでダメだということであれば、次のような事が考えられます。

CBRは単なるUDPの垂れ流しなので、送信相手からの返事が不要です。
FTPの場合は、FTPプロトコルによる相互通信になるため返事が必要です。
したがって、プロトコルオーバヘッドが発生します。

FTP/GENERICの場合、帯域を使いきる設定になっていない可能性があります。

UDPとTCPの差も考えられます。

いずれにせよ、いろんな可能性がありますが、
PHYレイヤスループットやMACレイヤスループットが期待した挙動を示しているのに、
より上位で異なる挙動になるのであれば、より上位の挙動を丁寧に調べるしかないです。