台風凄かったですね。

さて、添付して頂いたシナリオで以下を変更しました。

その1) PROPAGATION-CHANNEL-FREQUENCYの変更(これ重要です)
QualNetでは伝搬計算で使う周波数はCHANNELで指定します。
PHY802.11-FREQUENCY-BANDはdot11計算で使う数値なので、
伝搬計算では使われません。ちょっとわかりにくいです。

2.4GHzの場合
PROPAGATION-CHANNEL-FREQUENCY[0] 2400000000
5.0GHzの場合
PROPAGATION-CHANNEL-FREQUENCY[0] 5000000000

その2) 送信電力の変更
出力を弱くしました。左端で受信できないようにするためです。
PHY802.11-TX-POWER 10.0

その3) .appの変更
それぞれ、送信間隔を100MSにしました。
データ数が多いとシミュレーション時間がかかるためなので、
それ以外の意図はありません。
CBR 1 2 0 512 100MS 1S 0S

その4) .nodesの変更
Node2の移動開始位置を左端にして秒速1mにしました。
1 0 (828.00000000000000, 1249.00000000000000, 0.00000000000000) 0 0 0
2 0 (0.00000000000000, 1249.00000000000000, 0.00000000000000) 0 0 0
2 853S (853.00000000000000, 1249.00000000000000, 0.00000000000000) 0 0 0
2 929S (853.00000000000000, 1325.00000000000000, 0.00000000000000) 0 0 0

その5) ビルを2個削除
Node2を左端から移動させると、ビルを通り抜けるので
途中のビルを2個消しました。
具体的にはGUIでビルをクリックして右クリックで削除。

ここまでの変更でシミュレーション実行します。
Node2は左端から移動して、ビルの角で左折(上向き移動)。
その間100MS間隔でCBRパケットを送信。
送信電力が弱いので、Node1に接近しないと通信できません。

その時の受信電力とCBR Server側のパケット到着時刻と遅延を
グラフにしました。それぞれ横軸は時刻です。

まず、受信電力のグラフはQualNetが内部で選択したPathLossの
計算モデルもわかるようにしています。

2.4GHZの場合、
最初(距離が遠い場合)はURBAN_COST_WI_NLoS、
近づいてくるとTWORAY、
さらに接近するとFREESPACE、
ビルの角を曲がるとITU_R_NLOS1。
5.0HGzの場合はTWORAYがなくて、
最初(距離が遠い場合)はURBAN_COST_WI_NLoS、
近づいてくるとFREESPACE、
ビルの角を曲がるとITU_R_NLOS1。

いずれの場合もFREESPACEからITU_R_NLOS1に変化することで
かなり減衰してます(PathLossの絶対値が大きく変化する)。
角を曲がって大きく減衰することでCBRの受信できなくなってます。

次にCBRの遅延のグラフですが、横軸の開始は400からです。
2.4GHzの場合、概ね475秒から受信開始。
5.0GHzの場合、概ね565秒から受信開始。
という事で2.4GHzの方がより遠方から受信可能になってます。

角を曲がる(という楽曲がありましたね)ことでNLOSに変化し、
減衰するのですが、その減衰量が大きいためにいきなりCBRが
受信できなくなっている状態です。

ITU_R_NLOS1はITU-R P.1411で定められていて、ややこしい式なので
詳細は省略しますが、ビル壁からもう少し離すと良いかもしれません。
だだ、ITU-R P.1411のNLoS1にはover rooftopsと書いてあるので、
縦方向(Z軸方向)を考慮していて他の条件が影響するかもしれません。

『3.1.1 Propagation over rooftops, non-line-of-sight (NLoS)
The typical NLoS case (link BS1-MS1 in Fig. 1) is described by
Fig. 2. In the following, this case is called NLoS1.』

複数のファイルを添付することができないので、4回に分けて
添付します。
イメージデータがpng型式だとブラウザでプレビューできない
ことがあるみたいなのでjpeg型式にしてみました。