Bugzilla – Bug 871
naming for WifiPhyStandard
Last modified: 2015-01-14 18:22:24 UTC
The naming of WifiPhyStandard does not reflect anything you can find in IEEE Std 802.11-2007. I mean, if you look in the latter you won't find anything like "802.11a" or "802.11b". I understand that it is customary to use those names, but it generates confusion: for example, "802.11g" might refer to ERP_OFDM, ERP_PBCC, and somebody also uses it for DSSS_OFDM, which all have different characteristics and configuration settings. I propose to change our naming convention so that it matches with the standard and we eliminate any ambiguity. I would take the following steps: 1) make WifiHelper::SetStandard() deprecated (still working, but printing a warning suggesting to use the new API that I'll describe in the following) 2) define a new enum WifiPhySpecification that replaces WifiPhyStandard, and uses the same naming in IEEE Std 802.11-2007: OFDM_5Ghz, // IEEE Std 802.11-2007, Clause 17, a.k.a "802.11a" OFDM_5GHz_5MHz, // IEEE Std 802.11-2007, Clause 17, 5 MHz channel option OFDM_5GHz_10MHz, // IEEE Std 802.11-2007, Clause 17, 10 MHz channel option DSSS, // IEEE Std 802.11-2007, Clause 15 HR_DSSS, // IEEE Std 802.11-2007, Clause 18, a.k.a "802.11b" ERP_OFDM, // IEEE Std 802.11-2007, Clause 19.5, a.k.a "802.11g" DSSS_OFDM, // IEEE Std 802.11-2007, Clause 19.7, a.k.a "802.11b/g" 3) define the method WifiHelper::SetPhySpecification(enum WifiPhySpecification) which is the new API for the user 4) revise how we provide support for vehicular communications: 4a) IEEE 802.11p and IEEE 1609.4 (WAVE) say that OFDM_5GHz_10Mhz is used as-is, so we don't need a new WifiPhySpecification. 4b) for vehicular communications, QoS support (802.11e) is used, but with different parameters than regular 802.11; this was the main reason why changeset 5747 introduced the WifiPhyStandard 80211p_CCH and 80211p_SCH. Since this is really a MAC issue, and not at all a PHY issue, it should be solved by creating a new WifiMac (say WaveWifiMac), and having a new 4c) changeset 5747 affected also Qsta and Qap, but this should not be the case, as vehicular standards define their own BSS - they call it "Wave Basic Service Set (WBSS)" - and they do not use the regular association/deassociation procedures. Using Qadhoc as a substitute makes sense, but not using Qsta/Qap. (my apologies for not reviewing the patch that became changeset 5747 when it was time...) 5) rename wifi modes accordingly, maybe something like "wifia-18mbs" -> "OFDM_5GHz_18mbs" and so on and so forth.
(In reply to comment #0) I'm completely in favour of decoupling the current WifiPhyStandard enumeration from objects and activities relating to lower MAC and PHY operation, but I still see a use for something like the current WifiPhyStandard type. The primary purpose that I see a WifiPhyStandard (or similar) type serving is to allow a simulation or helper to specify how a Wi-Fi node (obviously comprising MAC and PHY) should be configured. Specifically, the simulation or helper needs to be able to say things like: - "This Wi-Fi node should support DSSS and HR-DSSS rates" (WIFI_PHY_STANDARD_80211b) - "This Wi-Fi node should support DSSS, HR-DSSS, and ERP-OFDM rates" (doesn't exist yet, but might be WIFI_PHY_STANDARD_80211g - see discussion under Bug 852) - "This Wi-Fi node should support OFDM (Clause 17) rates with 20 MHz channel spacing" (WIFI_PHY_STANDARD_80211a) - "This Wi-Fi node should support OFDM (Clause 17) rates with 5 MHz channel spacing" (WIFI_PHY_STANDARD_80211_5Mhz) I'm not sure that the WifiPhySpecification enum proposed for step 2 in your comment readily allows such things. I think the key issue is that we need to decouple configuration of a node (including determination of the rates that node's PHY should support), and the information related to those rates that is necessary for the node to operate once configured (e.g., Modulation Class, spectral signature descriptors, etc.). Something like the current WifiPhyStandard is useful for the former, but for the latter we need something that follows the standard a little more closely along the lines that you propose in step 2. I've proposed some code at: http://codereview.appspot.com/986041 ..., which attempts to do this by introducing a type that corresponds to the notion of Modulation Class described in IEEE 802.11-2007, Section 9.6.1, Table 9-2. The patch also adds coding rate information to the WifiModes and centralises their construction into a single WifiModeFactory method. The rates are also renamed with reference to the part of the standard that defines them. WifiModes no longer have an associated WifiStandard, but the latter type still exists and is used to imply the set of WifiModes that a MAC/PHY pair will support. I'd appreciate comment on this code. I haven't addressed any of step 4. That seems to me to be sufficiently distinct from steps 1 to 3 to warrant a separate bug.
The code reviewed at http://codereview.appspot.com/986041 but modified to fit with the recent Wi-Fi error model changes, has been pushed as changeset 6360:d8975477ff6a on ns-3-dev. This addresses 1, 2, 3, and 5 in the bug description. I believe that item 4 is a distinct issue (though I don't claim to understand exactly what is being proposed here). Hence I would like to resolve this bug as fixed and, if Nicola would be so kind, get a new one raised for whatever needs to be done for 4. Is this acceptable?
(In reply to comment #2) > I believe that item 4 is a distinct issue (though I don't claim to understand > exactly what is being proposed here). Hence I would like to resolve this bug as > fixed and, if Nicola would be so kind, get a new one raised for whatever needs > to be done for 4. > > Is this acceptable? After out-of-band comment in the affirmative from Tom, I've raised Bug 945 to capture Nicola's item 4 above. I'm hence marking this bug resolved fixed.