[Ns-developers] 802.11e NAV-handling

[kirillano]

Hi All,

  I have observed a strange problem with CTS/RTS mechanism, when running two wireless stations in ad-hoc mode:
When station1 sends an RTS, station 2 answers by CTS a SIFS after RTS.
  If CTS transmission is failed (due to physical error), the second RTS (sent by CTS-timeout)is dropped, because NAV is set. But, because only two stations were running, this situation is unreachable. (See picture in attachment for details)
  I started to look through the code and have found a strange thing: we set NAV for packet, which we transmit (and NotifyNav does sets a NAV), and in described case we have the following: when a station sends a CTS (after RTS), it sets a NAV, and the second RTS (sent by second station after CTS-timeout) is dropped by NAV. But, in this case station must not drop RTS.
  As it was said in comment, setting NAV for transmitted packets was made to satisfy chapter 9.9.1.4 of 802.11e, but this chapter says: if we have time (indicated by NAV) to pass more packets of the same AC, we can do it (and another AC will not access the channel). But we must never set NAV for transmitted packets (see 9.2.5.4 of 802.11-2007). If we set NAV for transmitted packets - all queues shall be locked, rather than all but transmiiting current packet.

Should we pass information to dcf-manager about frame exchange sequences instead of setting NAV?

Regards, Kirill Andreev
IITP RAS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NAV_bug.png
Type: image/png
Size: 24136 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090605/67a882fb/NAV_bug-0001.png