The patch overall looks good. A couple of comments:
3) maybe also add a Configure80211a and Configure80211b to WifiMac. Erm,
for the 802.11b PHY contributed by gary. If you can't bother with
> Hello,
>
> I would like to submit for code review the attached patch implementing half
> and quarter-clocked Wifi operation using 5 and 10 Mhz channels spacing. We
> would be glad to merge this new functionality in the main branch if ns-3
> developers think it may be interesting for other people. The following files
> have been modified (ns-3-dev):
>
> src/devices/wifi/interference-helper.cc
> src/devices/wifi/interference-helper.h
> src/devices/wifi/wifi-phy.cc
> src/devices/wifi/wifi-phy.h
> src/devices/wifi/wifi-phy-standard.h
> src/devices/wifi/yans-error-rate-model.cc
> src/devices/wifi/yans-wifi-phy.cc
> src/devices/wifi/yans-wifi-phy.h
> src/helper/nqos-wifi-mac-helper.cc
> src/helper/nqos-wifi-mac-helper.h
> src/helper/qos-wifi-mac-helper.cc
> src/helper/qos-wifi-mac-helper.h
> src/helper/wifi-helper.cc
> src/helper/wifi-helper.h
>
> Apart from the modifications pointed out in the previous email posted some
> weeks ago, we have also modified some of the wifi helpers. In order not to
> make the user set weird values for the MAC parameters (slot,sifs, etc) from
> the script, we have modified the WifiMacHelper incorporating two new
> functions (Configure80211_10MhzParameters and Configure80211_5MhzParameters)
> that allows the user to automatically select the default MAC parameters for
> 5Mhz and 10Mhz channel spacing (we have also moved the function SetType and
> the ObjectFactory m_mac from NqosWifiMacHelper and QosWifiMacHelper to
> WifiMacHelper).
>
> Looking forward to your comments.
>
> Best regards,
> Ramon Bauza.
>
> 2009/5/29 Ramon Bauza <
monbauza@...>
>
> > Hello everyone,
> >
> > I am Ramon Bauza, a researcher at Miguel Hernandez University (Spain).
> > Currently, I am involved in the EU FP7 project iTETRIS which aims at
> > creating an integrated traffic and wireless simulation platform that will
> > allow evaluating traffic management strategies and communication protocols
> > in vehicular environments. The iTETRIS project employs SUMO and ns-3 as
> > traffic simulation and wireless simulation platforms respectively.
> >
> > Our research group at UMH, it is charge of implementing the 802.11p (WAVE)
> > standard in ns-3. 802.11p is based on 802.11a, being the channel bandwidth
> > and thus also the data rates the main differences between both (802.11p uses
> > a 10Mhz whereas 802.11a uses 20Mhz). After implementing 802.11p in ns-3, we
> > will also look into and implement propagation models for vehicular
> > environments that consider LOS/NLOS visibility conditions,
> > vehicle-to-vehicle and vehicle-to-infraestructure communications, and
> > shadowing and multipath fading effects.
> >
> > In order to model a 10Mhz channel in ns-3, some additions/modifications
> > should be done (some weeks ago I posted a message in the user mailing list
> > regarding this
> >
http://groups.google.com/group/ns-3-users/browse_thread/thread/f27b1ddcf9f1d532#).
> > Apart from 802.11p, I think other 802.11 standards employ 10MHz channels and
> > thus probably the modeling of 10Mhz channels would also be useful for the
> > ns-3 community working on 802.11-related topics. In fact, the IEEE Std
> > 802.11TM-2007 standard considers 10Mhz channel spacing using OFDM. If you
> > consider that the modeling of 10Mhz channels may be beneficial for other
> > users we would be glad to merge the 10Mhz modeling in the main branch.
> >
> > Below, I compile the needed functions and modifications we plan to
> > introduce in ns-3 at the PHY layer for modeling a 10Mhz channel:
> >
> > + wifi-phy-standard.h
> >
> > Add WIFI_PHY_STANDARD_80211_10Mhz in the enum WifiPhyStandard
> >
> > + wifi-phy.h and wifi-phy.cc
> >
> > Declare and define the following new functions:
> >
> > static WifiMode Get3mb10Mhz (void);
> > static WifiMode Get4_5mb10Mhz (void);
> > static WifiMode Get6mb10Mhz (void);
> > static WifiMode Get9mb10Mhz (void);
> > static WifiMode Get12mb10Mhz (void);
> > static WifiMode Get18mb10Mhz (void);
> > static WifiMode Get24mb10Mhz (void);
> > static WifiMode Get27mb10Mhz (void);
> >
> > + yans-wifi-phy.h and yans-wifi-phy.cc
> >
> > Declare and define the void Configure80211_10Mhz (void) function.
> > Modify the void SetStandard (enum WifiPhyStandard standard) function so
> > that the user can also select a 10Mhz channel.
> >
> > + interference-helper.h and interference-helper.cc
> >
> > Declare and define void Configure80211_10MhzParameters (void);
> >
> > One function that should be modified is
> > InterferenceHelper::CalculateTxDuration (uint32_t size, WifiMode
> > payloadMode, WifiPreamble preamble) const since it assumes that the symbol
> > duration is always 4us (20 Mhz channel). This function should employ a
> > symbol duration according to the channel used (10Mhz or 20Mhz). One possible
> > solution to solve this would be to have a new variable in the class
> > InterferenceHelper which allows differentiating the channel used. This
> > variable could be of type WifiPhyStandard. In the function Time
> > InterferenceHelper::CalculateTxDuration, this new variable would be examined
> > and the packet txon duration will be calculated based on the bandwidth
> > channel.
> >
> > Please, I would like to have your comments on this in order to proceed with
> > the implementation.
> >
> > Thank you in advance.
> > Best regards,
> > Ramon.
> >
> > --------------------------------------------------------------------------
> > Ramon Bauza
> > Ubiquitous Wireless Communications Research Laboratory
> > Uwicore,
http://www.uwicore.umh.es> > Signal Theory and Communications Division
> > University Miguel Hernández (Spain)
> > Tel: +34 96522 2031
> > Fax: +34 96665 8903
> >
> > ----------------------------------------------------------------------------
> >