はじめまして、こんばんは。

QualNet 4.0でRTS/CTSフレームとデータフレーム(+ACK)を異なるチャネルを用いて通信したいと考えております。

RTS/CTSはある決められた1つのチャネルで、データフレームは残りのチャネルで通信します。
そのため、送受信端末共にRTS/CTSフレーム交換の後とデータフレーム交換の後にチャネル切り替え動作を行います。

衝突などでフレームが落ちた場合には、送受信端末共にRTS/CTSフレーム交換用チャネルに切り替えてもう一度RTS/CTSフレーム交換からやり直すのですが、
このときPhyStatusがPHY_IDLEにならずPHY_SENSINGとPHY_RECEIVINGを遷移しているだけとなり、よってその端末は以後ずっと通信を行えない状態に陥ることがあります。

通信を行えない状態に陥った端末の電波の及ぶ近隣では、何事も無いようにDifsやバックオフの待機の後通信を行っていることなどからチャネルを切り替えがまずい可能性が高いと考えられます。

物理層に詳しい方などおられましたら、原因などご教授いただければと思います。

なお、チャネルの切り替えは
mac_dot11-mgmt.cpp にある MacDot11ManagementChangeToChannel() と同様のコードをmac_dot11.cppに追加して利用しております。

こんにちは

＃改造コードのデバッグに関する投稿だと、説明するのも回答するのも厳しいものがありますね。
＃地道にデバッグするしかなさそうですが。

PhyStatusがPHY_IDLEにならない理由として考えられるもの：
1.周りのノードが電波を出し続けている
2.チャネルマスクの設定が悪く、自送信信号を受信して(？)変なループに入っている
3.干渉量interferencePower_mWの値がSignalEnd時の減算処理されず、常にキャリアセンスのしきい値rxSensitivity_mWを上回っている

「1」だとすると、いただいた説明だけではお手上げです。
「2」は可能性としては捨てきれないですが、どこかでアサーションに引っかかりそうな気もします。またQualNetのアーキテクチャ上、送信信号を自ノードが受信できるのか不明です。
「3」が一番可能性が高そうなので、以下はその可能性について一例を示します。

PHYモデルの使用状況が分からないので、以下の前提を立てます。
* PHY-MODELはPHY802.11a/bを使用あるいは流用・改造している
* PHY-MODELのソースコードについて、ある程度内容を把握している
* PHYレイヤ管理変数(802.11だとPhyData802_11構造体)はインタフェースごと(phyIndexごと)にしか管理しておらず、チャネルごとには管理していない

PHYにおいて、たとえばあるチャネルで何らかの干渉波の信号を受信途中で、interferencePower_mWに値が入っていたとします。
その干渉波信号のSignalEndイベントが発生する前にチャネルを切り替えたとすると、
チャネルマスクの設定により受信中の干渉波のSignalEndイベントがおそらくあがらなくて、interferencePower_mWは減算されないことがあるかもしれません。
切り替え先のチャネルで新たな干渉波を受信したときに、interferencePower_mWに値が加算されてしまいます。
クリアされなかったinterferencePower_mWの値がキャリアセンスのしきい値rxSensitivity_mWを上回っていたとすると、
PhyStatusがいつまでもPHY_IDLEにならないということになります。

interferencePower_mWに限らず、構造体PhyData802_11のメンバ変数のうちチャネル切り替えに影響するものは、
チャネル切り替え時に整合を取るか、チャネルごとに独立に管理する必要があるのではないでしょうか。

不備な質問をしてしまい申し訳ありませんでした。以後、気をつけたいと思います。
それにも関わらす、詳細なご回答をいただきありがとうございます。

まず、補足ですが
* PHY-MODELはPHY802.11a/bを使用しています
* PHY-MODELのソースコードはフレーム送受信を中心に読んではいますがまだ十分な理解とは言えません
* PHYレイヤ管理変数(PhyData802_11構造体)もインタフェースごと(phyIndexごと)にしか管理していません

さらに、ANTENNA-MODELにはOMNIDIRECTIONALを用いています。

また、
引用：
理由を調査した結果、理由は3ではないかと思います。

そのため、ipotenさんがおっしゃるように、
構造体PhyData802_11のチャネル切り替えに影響するメンバ変数をチャネル切り替え時に整合を取ろうと思います。
そこで、すみませんがinterferencePower_mWの整合を取るためにもう1つ質問させて下さい。

interferencePower_mWの値変化のさせ方は、
* 関数PHY_SignalInterference()の利用(関数Phy802_11TransmissionEnd()内など)
* 直接入力(関数Phy802_11SignalArrivalFromChannel()内のphy802_11->interferencePower_mW += rxInterferencePower_mW;など)

に分類できると思いますが、両者はどのようにすみ分けされているのでしょうか？

私の理解が甘いだけかもしれませんが、関数PHY_SignalInterference()さえ利用すればinterferencePower_mWは適切に更新できるような気がしますが、それではまずい状況などありますでしょうか？

以上です。よろしくお願いいたします。

こんにちは

引用：
私の理解している範囲では、
* 直接入力：PHYの送受信の開始・終了タイミングイベントでそのつど増減されるもの
* 関数PHY_SignalInterference()の利用：チャネルマスクなどにより受信イベントが上がらなかった分の干渉電力を更新
と思っています。

関数PHY_SignalInterference()は、その時点の、指定したノードが受信している希望波と全干渉波の電力を返すAPIですが、いかんせんソースが非公開なので実際のところどんな処理をやっているのか詳細は分かりません。
使い分けられている意図は不明ですが、直接入力の計算をしている箇所でPHY_SignalInterference()を使っていないのは、もしかしたら単に計算スピードとかの問題かもしれませんね。

直接入力の計算をしている箇所でPHY_SignalInterference()で置き換えられるのか(同等の値が取れるのか)分かりません。
面倒でなければ、直接入力の計算をしている箇所でPHY_SignalInterference()の計算も行って、それぞれの値を比較出力して確認されてみてはいかがでしょうか。

＞ipotenさん
こんにちは。遅くなってしまいましたが、ご回答ありがとうございます。

interferencePower_mWに関しては、おそらくチャネル切り替え時に関数PHY_SignalInterference()を利用すれば整合が取れるのではないかと考えました。
これにより、正常に動作しているらしき結果が得られました。

ただし、確実なシミュレーションを行うためにも以下を参考に上記の修正が正しいかどうか確認したいと思います。

引用：

引用：

以上です。お世話になりました。
今後ともよろしくお願いいたします。