こんにちは。
当方、QualNet5.0.2を使っています。

現在、MAC層における処理について検証しているのですが
mac_dot11.cpp内にあるMacDot11ProcessNotMyFrame関数における処理において、分からない点があるので教えて下さい。

例として、以下のようなオムニノードが配置してあるとします．

Ａ　Ｂ　Ｃ
○　○→○

ＢがＣに対してRTSの制御メッセージを送信した場合、当然、Ａも受信することができます。この時、MacDot11ProcessNotMyFrame関数においてＡはNAVを設定するための処理を以下の通り行います。

NewNAV = currentTime + duration + EPSILON_DELAY;
if (NewNAV > dot11->NAV) {
dot11->NAV = NewNAV;
navHasChanged = TRUE;
}

この場合、NewNAVに代入された値がdot11->NAVに代入されることで、その時間までのNAV期間として処理されると認識しています。
しかし、ＢがＣからのCTSを受信後、DATAパケットを送信した際に、ＡはDATAパケットを受信することになりますが、再びMacDot11ProcessNotMyFrame関数で上記の処理を行う際に、dot11->NAVが先程のRTSで設定したdot11->NAVの値よりも大きくなることで上書きする処理を行うことになります。これは、おかしな動作だと個人的には思うのですが、処理的に問題ないのでしょうか？

私が認識しているのは、RTSを受信した際にNAV期間を設定（t1とします）し、そのNAV期間が切れるのはt1にも関わらず、上記の処理によってt2にNAV期間が切れるといったことになっているように感じます。
DATAパケット自体にNAVを設定する機構はないと思いますので、この処理は不可解です。

この処理を意図的に行わせることによって、整合性などを図っているのでしょうか？
もしくは、dot11->NAVに対する考え方（NAV期間が切れる時間）が間違っているのでしょうか？
それとも、この質問自体がおかしなことを言っている？？

よろしくお願いします。

はじめまして。
802.11 RTS/CTS の詳しい規格を知らないので、どういった処理が正しいのかは分からないのですが、
少し気になったのでNAV期間について、ざくっと調べてみました。

引用：Wireless LAN - IEEE802.11 Frame Format

とあります。これを表すQualNetの変数は、hdr->durationだと思われます。

そこでQualNet5.0で確認してみたところ
QUALNET_HOME\libraries\wireless\src\mac_dot11-sta.h
MacDot11StationTransmitRTSFrame()では、

hdr->duration = (UInt16) MacDot11NanoToMicrosecond(
　dot11->extraPropDelay + dot11->sifs +
　PHY_GetTransmissionDuration(node, dot11->myMacData->phyNumber, dataRateType, DOT11_SHORT_CTRL_FRAME_SIZE) +
　dot11->extraPropDelay + dot11->sifs +
　packetTransmissionDuration +
　dot11->extraPropDelay + dot11->sifs +
　PHY_GetTransmissionDuration(node, dot11->myMacData->phyNumber, dot11->dataRateInfo->dataRateType, DOT11_SHORT_CTRL_FRAME_SIZE) +
　dot11->extraPropDelay);

MacDot11StationTransmitDataFrame()では、

hdr->duration = (UInt16) MacDot11NanoToMicrosecond(
　dot11->extraPropDelay + dot11->sifs +
　PHY_GetTransmissionDuration(node, dot11->myMacData->phyNumber, dataRateType, DOT11_SHORT_CTRL_FRAME_SIZE) +
　dot11->extraPropDelay);

というふうに、送信時にDurationがセットされているように読めました。＊見やすさのためコード整形してます。
DATAパケットのDurationがRTSのDurationよりも短く計算されているようなので、どうも意図的に設定しているのではないのかなと思います。

hinaさん

返答遅れて申し訳ありません。
ご指摘通り、以下の関数
MacDot11StationTransmitRTSFrame()
MacDot11StationTransmitDataFrame()
を確認してみたところ、DurationのセットはRTS＞DATAのように計算しているみたいですね。
これは当たり前のことなので納得ですし、やはり意図的に動作しているようですね。

MacDot11ProcessNotMyFrame関数内にある
NewNAV = currentTime + duration + EPSILON_DELAY;
if (NewNAV > dot11->NAV) {
dot11->NAV = NewNAV;
navHasChanged = TRUE;
}

は、CTSなどの返答がなかったときに、再度RTSなどを再送した際に
前回のRTSによるdurationを更新するために、このような処理にしているようですね。
この関数内には以下のように

// This is what we should do.
//
//if (isARtsPacket) {
　…
// }

が閉じてあったりなど、引数としてのisARtsPacketなどが使用されている形跡が全くないので、RTSやCTSを意図的に分けたりしていることはないようですね。この辺りは、コード上のコメントにも書いてある通り、何か処理が必要な場合はこちら側で改変する必要があるようですね。

っというように、関数内における処理が一体どういう狙いで書いてあるのか色々と分かりましたので、良い勉強になりました。
hinaさん、ありがとうございました。