Bugzilla – Bug 2412
align WifiPhy frequency and channel number
Last modified: 2016-07-21 01:43:38 EDT
Problem: WifiPhy Set/GetFrequency and Set/GetChannelNumber are ill defined. Frequency is being set to 2407 MHz for the 2.4 GHz band and 5000 MHz for the 5 GHz band, regardless of what channel number is being used. Frequency is documented as trying to track the channel 'starting' frequency, but it is harder to define this than the center frequency. Frequency and channel number are both attributes of YansWifiPhy, but they are related. In general, it is difficult to have two attributes control a single underlying value because of static initialization order issues. Proposal: - make ChannelNumber attribute govern the setting of frequency also. - make Frequency attribute gettable only (disable Set capability on the attribute) - define Frequency to be the channel center frequency, instead of the starting frequency - store the mapping of channel number to center frequency internally in some std::map containers Users are then supposed to set 'ChannelNumber' attribute to change the channel and frequency, and if unset, the setting of the WifiPhyStandard will by default, configure 2.4 GHz Phys onto channel 1, and 5 GHz Phys onto channel 36 (exception: 802.11ac configures onto channel 42 by default) Out of scope: - this patch revealed that the mesh module (the MeshHelper) sets the ChannelNumber to invalid values (default 0). I just patched this to make it workable for now, but more rework of mesh module to make it frequency agile could be the subject of a separate bug - the static std::maps used to store the map of channel number to frequency could be more cleanly written with C++11 initializer lists; this can be redone once the patch to bug 2270 is merged. - I started to try to move this code from YansWifiPhy to WifiPhy, but it started to get complicated, so I suggest that it could also be done in a more general refactoring at a later date
Created attachment 2436 [details] suggested patch
Tom, do you have some updates about the refactoring of your previous patch?
Created attachment 2463 [details] suggested patch improved patch
I uploaded a better patch for this issue. The main change is that (center) Frequency and ChannelWidth are now proposed as the attributes that will be really used by the model code, and ChannelNumber and WifiHelper::SetStandard are more like convenience attributes/methods to configure these things. The basic idea is that ChannelNumber and Frequency are related; by changing one, the other value is changed. ChannelNumber must be set to a value defined by the standard in effect (e.g. setting channel number to 14 for 802.11ac is not a valid combination). Users can define their own channel numbers at runtime for later use in their programs. However, Frequency and ChannelWidth are what ultimately get used by the underlying model. I've attached a complete patch; the individual commits can be viewed (and commented on, if you prefer) here: https://github.com/tomhenderson/ns-3-dev-git/commits/ns-3-dev-bug-2412 The first commit is the patch for issue 2270 (which will be committed shortly). The remaining 8 commits are proposed for ns-3-dev such as laid out in the git repository. From my perspective, this is ready to merge (test, example, documentation completed) unless any comments are received.
I've just quickly looked and I don't have comments so far.
Tom to push the patch
Created attachment 2498 [details] revised patch Fixed issue reported by N. Sapoval regarding the fact that the WifiPhyStandard is often set later in the configuration than the ChannelNumber, so some consistency checking must be deferred. Also updates RELEASE_NOTES and CHANGES.html. Current patch depends on patch to bug 2452 (Object::IsInitialized ()).
Tom, I did not test, but the patch looks ok.
pushed in changeset 12215:ffa8e03e95f4