こんにちは
電子レンジのようにwifiの通信を約10msごとに妨害する端末を設置し、通信スループットを下げたいです。
妨害端末が送信しないことにはビーコンしか出さないので妨害端末のudp通信を受信する端末も設置、ソースコードを変更し、message apiを使うことで10msごとに妨害端末のTxpowerを-40dbmから10dbm,10dbmから-40dbmに変化するようにさせました。
しかし結果として、Txpowerを変化させないときのスループットと比較して、スループットは全く変わりませんでした。
どなたかご教授いただけないでしょうか、よろしくお願いします。
versionは7.4です。

zipファイルを載せておきます、configファイル等入ってます。
2_4_ghz.zip

こんにちは wireless_ さん

シナリオの設定とソースコード変更についていくつか明確にしたいです。

・「妨害端末」というのが、妨害を与える側 (与干渉ノード・例として電子レンジを想定したもの) でよいでしょうか。
・「妨害端末」は添付されたシナリオのどのノード(ID)に該当しますか？
・「妨害端末のudp通信」というのは具体的には何をしていますか？
もっというと、どのレイヤから妨害の元となるデータを送信しているでしょうか。
MACレイヤには何かソースコードの改編、あるいは設定変更を行っていますか？


以下はいくつかの仮定の上で起こっているであろうことを想定して書いてみます。

もしMACやPHYのモデルをなにもいじっていない場合、MAC802.11 はキャリアセンスをして干渉を回避します。
「妨害」の通信をMACより上のレイヤからデータパケットとして送信している場合、
トラフィックの量や帯域設定によりますが、帯域に余裕がある状況ではお互いに干渉を回避しながら通信するため
スループットは変わらないと思います。

実世界の電子レンジのような干渉源は、パケット通信のような断続的なものではなく、
バースト波が電力を上下させながら連続的に発生するものと思います。
QualNetはおおざっぱにいえばパケットシミュレータなので、このような連続波による干渉を模擬することには向いていません。
もし疑似的に行おうとすると、パケットをすき間なく連続で送信するように設定し、MACやPHYも改変する必要がありそうです。

ipotenさん返信ありがとうございます。

すみません、configファイルを変更したので上げなおします。
この構成で電子レンジのtxpowerを変更したシュミレーションを行うと妨害端末側のネットワークが3Mbit/sec、被妨害端末側のネットワークが20Mbit/secになり、電子レンジ側が通信できない分を被妨害端末側のネットワークが通信するだけという結果になってしまいました。(txpowerを変えないときは両ネットワークとも12Mbit/sec)

>「妨害端末」というのが、妨害を与える側 (与干渉ノード・例として電子レンジを想定したもの) でよいでしょうか。

はい、そうです。

>「妨害端末」は添付されたシナリオのどのノード(ID)に該当しますか？

(新しく上げたconfigファイルで)nodeid6です。
micro_wave_ovenというhostnameになっています。

・「妨害端末のudp通信」というのは具体的には何をしていますか？
もっというと、どのレイヤから妨害の元となるデータを送信しているでしょうか。

cbrを使っただけでした、電子レンジが20ms周期で電力パワーを変えて、約10ms間、csmaのキャリアセンスレベルを超えてしまって通信できなくなる、という記述を見たので。

>MACレイヤには何かソースコードの改編、あるいは設定変更を行っていますか？

txpower以外はいじってません。

phy802_11->modeをずっとTRANSMITTINGで固定できたらいいんですけど、それか新しいプロトコルを一から作るか。どちらにしろ大きな改変が必要ですかね
2_4_ghz (2).zip

wireless_ さん

妨害波の送信を模擬する新規のモデルを実装するというのが正攻法なのですが、大変だと思います。
既存のモデル(できれば wireless_ さんが試されているwifiのシナリオ)の設定と最小限の改修で、なにかそれっぽい模擬ができないか考えてみます。
ヒントになればよいのですが。。

●妨害端末側のキャリアセンスを回避する方法
　現在の設定では、妨害端末側も802.11のMAC/PHYをそのまま利用しているため、周りで誰かがしゃべっていると妨害波を出せないという現象になっていると思います。
　例えば妨害端末だけリスニングチャネルをマスクしてしまうというのを思いついたのですが、私の試しではチャネルを聞かずに送信だけして干渉を与える設定がうまくいきませんでした。
(どなたかこうすればよさそう問うのをご存知でしたら教えてください。)
　もう一つ思いついたのは、wireless_ さんのシナリオで使われている PHY802.11a で、PHY802.11-RX-SENSITIVITY-xxMBPS を大きな値にするというものです。
受信感度が下がって受信処理がされなくなるため、送信機会が増えます。
　問題は、PHYのレベルで受信ができなくなるため、ルーティングが通らなかったり、MACレベルでも制御シーケンスのやり取りができません。
これだと wireless_ さんの設定されているような CBR (上位のアプリケーション) で妨害波を送信することはできないことになります。
　理想的にはPHYやMACから直接ブロードキャストするようなコードを追加するのがよさそうです。
もし現在のシナリオのwifiをそのまま使うのだとすると、例えば妨害端末の該当インタフェースの MACDOT11 の設定で、Beaconフレーム(ブロードキャスト)を送信しまくるというのはどうでしょうか。
MAC-DOT11-BEACON-INTERVAL を最小の 1 にするなどすれば、被妨害端末に大きな干渉を与え続けることができます。

●妨害端末が電波を吹き続ける方法
　QualNetのパケットメッセージの仕組みを利用する限り、妨害波はとぎれとぎれになってしまいます。
　送信信号のDurationをシミュレーション時間を超えるような長大な時間になるようにするという方法が考えられます。
アプリケーションなどの上位レイヤでサイズを大きくしても各レイヤ/プロトコルの制限で短くなってしまうため、MACやPHYで直接設定するのがよさそうです。
先程の例を適用するとすると、MACでBeaconフレームを送信する MacDot11ApTransmitBeacon() あたりでBeaconのフレームサイズやDurationを特定の妨害端末の場合にながくするように変更します。
これはソースコード改修が必要です。
　上記では一つ問題があります。
wireless_ さんは一定時間ごとに妨害波の送信電力を変化させるようにしていますが、送信電力はQualNetでは信号の送信開始点で(その終わりまで)固定されてしまうため、電力の変化が反映されません。
送信電力の変化のタイミングに同期して、送信信号を送り直すのがよさそうです。
先程の例だと、Beaconの送信間隔をうまく設定すればできそうです。
このときすき間なくBeaconを送信するには、やはりDurationをいじる必要があります。

●妨害端末が電波を吹くのではなく、被妨害端末側で妨害波の受信電力を計算で模擬する方法
　妨害端末側で色々設定・改修するのではなく、被妨害端末側で妨害波の受信電力を計算で模擬する方法も考えられます。
ソースコードの改修が必要です。
　受信側のPHYで各種の受信イベントがありますが、キャリアセンスやSINRを計算する際の雑音(N)や干渉(I)の電力に、その端末が受信するはずの妨害波の電力を上乗せします。
　妨害波の送信電力は、メッセージ等を使わずとも現在のシミュレーション時刻から -40dBm か 10dBm かは決定できると思います。
　妨害波の受信電力の計算はどこまで厳密に模擬したいかによりますが、送信電力に対して送信側・受信側のそれぞれのアンテナゲインの加算とパスロス分の減算が必要です。
パスロスの計算には、妨害端末と自端末の位置やアンテナの高さなどの情報が必要になります。

■その他気になること：チャネルの問題
　被妨害端末がwifiの特定チャネルだけを使用しているのであれば、妨害端末側も同じwifiの特定チャネルで吹くことでひとまずよさそうです。
現実の電子レンジのようにwifiに比較して広い帯域で干渉し、被妨害端末側で複数のチャネルを利用するのであれば、別の方法を考える必要があります。

※参考情報
QualNetの製品系列に EXata-Cyber というのがあり、Wireless Jamming Model という機能を持っているようです。
製品をお持ちではないと思うので直接利用はできないですが、QualNetのソースコード上で一部の実装コードを見ることができるので参考になるかもしれません。
のキーワードで探すことができます。

思いつくままに書いてみましたが、どれもそれなりの試行錯誤は必要そうですね。

ipotenさん　ありがとうございました。beacon interval 最小、durationを変更することで誤差はありますが無事一定周期でbeaconを送信出来るようになり、ap側のネットワークを妨害することが出来ました。フレームを変更する必要はありませんでした。
複数のチャネルは考えてないので大丈夫でした。
また妨害電力はstarttransmitting関数の中で電力を変更したので、設定に反映することが出来ました。(dbファイルで確認済み)

非常に助けになりました、また機会がありましたらよろしくお願いします。