Bug 2496 - questions about Wifi supported rates element
questions about Wifi supported rates element
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: wifi
unspecified
All All
: P5 normal
Assigned To: sebastien.deronne
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-09-08 14:42 EDT by Tom Henderson
Modified: 2016-09-28 00:19 EDT (History)
1 user (show)

See Also:


Attachments
possible patch to fix (6.36 KB, patch)
2016-09-13 00:59 EDT, Tom Henderson
Details | Diff
possible patch to fix (updated) (7.56 KB, patch)
2016-09-13 18:49 EDT, Tom Henderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2016-09-08 14:42:52 EDT
Reported from a user:

- I've noticed that the Supported Rates element starts with an 0x80
octet, which is not valid (it would indicate that support for zero Mbps
is mandatory)

- I think the problem is that the code is passing in the HT BSS
membership selector value (127, HT_PHY) into SupportedRates but
this promptly gets divided by 500k (in AddSupportedRate/SetBasicRate)
so ends up as 0

- I tried to fix that by special-casing values < 128, so that the
SupportedRates element would correctly start with the octet 0xff,
indicating that support for HT was mandatory in the BSS

- However, this promptly caused assertions in mac-low.cc, to do
with the MAC duration (NAV) being less than 0

- Looking at the pcap output, I can indeed see some oddness, specifically
that some control responses (Acks) are being sent at 54 Mbps rather
than 24 Mbps (the highest basic rate) in one direction.  So I think
the problem happens when one end assumes the control response will come
back at 54 Mbps, but it actually comes back at 24 Mbps, taking more time
than allowed by the TXOP holder (in the NAV, i.e. here the Duration field
of the frame sent by the TXOP holder)

- This is where I got stuck.  The presence of a BSS membership selector
(HT_PHY) in the supported rates does not change the basic rate set and
so does not change the rates that are valid for control responses.
Both sides should still be assuming that control responses will come
back at 24 Mbps

So I think there's something wrong with the code which works out the
rate to use for control responses based on the basic rate set, which
in turn comes from the Supported Rates element (and corresponding
object), when the element contains a BSS membership selector.
Comment 1 Tom Henderson 2016-09-08 14:43:37 EDT
more information

> 
> P.S.: Note that in 802.11mc/D6.0 says in 9.2.5.1 that "If a calculated
> duration results in a negative value, the value of the Duration/ID
> field is 0."  However, this would just have hidden the control response
> rate problem, so I don't think just doing a if (d < 0) d = 0; is the
> right fix!
Comment 2 Tom Henderson 2016-09-13 00:59:43 EDT
Created attachment 2579 [details]
possible patch to fix

This patch correctly includes the special values for HT_PHY and VHT_PHY BSS membership selector set.
Comment 3 Tom Henderson 2016-09-13 18:49:39 EDT
Created attachment 2580 [details]
possible patch to fix (updated)

fix problem with previous patch
Comment 4 Tom Henderson 2016-09-28 00:19:51 EDT
pushed in changeset 12343:e23a54386653