add support for IEEE 802.11ac

add support for IEEE 802.11ac

[S. Deronne, 2015-08-28 16:35:01]

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/mac-low.cc
File src/wifi/model/mac-low.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/mac-low.cc#new...
src/wifi/model/mac-low.cc:3087: 
Commented lines can be ignored, this will be removed.

[S. Deronne, 2015-08-29 12:23:03]

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/mac-low.cc
File src/wifi/model/mac-low.cc (left):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/mac-low.cc#old...
src/wifi/model/mac-low.cc:1598: packetType = 1;
packet type should be 0 for VHT single MPDU, it will be changed asap in the
repository.

[Tom Henderson, 2015-08-31 05:05:08]

Sebastien, here are some comments; in general, it looks good.

Outside of my comments below, we need some tests of the VHT modes (at least,
turning the example 'validation' program into an "example-to-run"), and some
more documentation on what 802.11ac support is in scope and out of scope of the
model.

We also would need a CHANGES.html (and RELEASE_NOTES) about what API has changed
with WifiMode renaming.

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
File examples/wireless/ofdm-vht-validation.cc (right):

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
examples/wireless/ofdm-vht-validation.cc:28: 
what exactly is validated?  Please add comment.  Or should we move this to a
test suite?

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
File examples/wireless/vht-wifi-network.cc (right):

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
examples/wireless/vht-wifi-network.cc:28: //This is a simple example of an IEEE
802.11ac Wi-Fi network.
Please elaborate more what this example demonstrates and what kind of output it
produces.

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
examples/wireless/vht-wifi-network.cc:103: DataRate = StringValue (dataRate);
Why not avoid this C++ string handling in user programs and provide a helper:
e.g. 

DataRate VhtWifiMacHelper::DataRateForMcs (int mcs)

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
examples/wireless/vht-wifi-network.cc:121: Config::Set
("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/ChannelWidth", UintegerValue
(j));
See my comment on yans-wifi-phy.cc where I wonder if we could leave ChannelWidth
out of ConfigureStandard() for n and ac, thereby avoiding the need to do this
post-install override.

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
File src/wifi/helper/vht-wifi-mac-helper.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
src/wifi/helper/vht-wifi-mac-helper.cc:45: //who knows what they're doing can
override with explicit attributes.
I do not understand this comment

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
File src/wifi/helper/vht-wifi-mac-helper.h (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
src/wifi/helper/vht-wifi-mac-helper.h:41: * Create a QosWifiMacHelper that is
used to make life easier when working
copy-paste error?

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
File src/wifi/model/cara-wifi-manager.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
src/wifi/model/cara-wifi-manager.cc:189: channelWidth = 20;
I am not sure about these statements that are introduced into all legacy rate
controls.  What does it mean practically if the station supports a channel width
> 20 but the rate control sets it instead to 20?

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy.cc
File src/wifi/model/yans-wifi-phy.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:229: SetChannelWidth (22);
Why would this be different than 80211g; aren't the masks the same?

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:255: SetChannelWidth (20);
why not leave this "SetChannelWidth()" out of all ConfigureStandard methods that
have possibility of variable width, and then set it as attribute in the WifiPhy?

This would seem to avoid the need to do the Config::Set() operation after
Install() (which is kind of clumsy).

[S. Deronne, 2015-08-31 07:04:41]

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
File src/wifi/helper/vht-wifi-mac-helper.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
src/wifi/helper/vht-wifi-mac-helper.cc:45: //who knows what they're doing can
override with explicit attributes.
On 2015/08/31 05:05:07, Tom Henderson wrote:
> I do not understand this comment

I think this came from Ghada's file.
It can be removed I suppose.

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
File src/wifi/helper/vht-wifi-mac-helper.h (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
src/wifi/helper/vht-wifi-mac-helper.h:41: * Create a QosWifiMacHelper that is
used to make life easier when working
On 2015/08/31 05:05:07, Tom Henderson wrote:
> copy-paste error?

Yes, thanks I will change it.

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
File src/wifi/model/cara-wifi-manager.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
src/wifi/model/cara-wifi-manager.cc:189: channelWidth = 20;
On 2015/08/31 05:05:07, Tom Henderson wrote:
> I am not sure about these statements that are introduced into all legacy rate
> controls.  What does it mean practically if the station supports a channel
width
> > 20 but the rate control sets it instead to 20?

There could be an issue in 802.11b, so it should be > 22 or simply >= 40.

The idea of this statement is to avoid to use legacy rate adaptation for
802.11n/ac rates (or at least avoid it to play with different channel widths and
guard intervals).

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy.cc
File src/wifi/model/yans-wifi-phy.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:229: SetChannelWidth (22);
no this is different, channel width is 22 MHz in 802.11b and 20 MHz in 802.11g
(which is a like a copy-paste of 802.11a in the 2.4 GHz band)

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:255: SetChannelWidth (20);
On 2015/08/31 05:05:07, Tom Henderson wrote:
> why not leave this "SetChannelWidth()" out of all ConfigureStandard methods
that
> have possibility of variable width, and then set it as attribute in the
WifiPhy?
> 
> This would seem to avoid the need to do the Config::Set() operation after
> Install() (which is kind of clumsy).

The problem if we do not do this is that the user need to carefully set the
channel width.
Example: Since default is 20 MHz, a user using 802.11b will have to explicitely
indicate the channel width of 22.
This workaround then force the user to configure the channel width only if he
wants to change from default standard values.

[Tom Henderson, 2015-08-31 12:44:46]

On 2015/08/31 07:04:41, S. Deronne wrote:
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> File src/wifi/helper/vht-wifi-mac-helper.cc (right):
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> src/wifi/helper/vht-wifi-mac-helper.cc:45: //who knows what they're doing can
> override with explicit attributes.
> On 2015/08/31 05:05:07, Tom Henderson wrote:
> > I do not understand this comment
> 
> I think this came from Ghada's file.
> It can be removed I suppose.
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> File src/wifi/helper/vht-wifi-mac-helper.h (right):
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> src/wifi/helper/vht-wifi-mac-helper.h:41: * Create a QosWifiMacHelper that is
> used to make life easier when working
> On 2015/08/31 05:05:07, Tom Henderson wrote:
> > copy-paste error?
> 
> Yes, thanks I will change it.
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
> File src/wifi/model/cara-wifi-manager.cc (right):
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
> src/wifi/model/cara-wifi-manager.cc:189: channelWidth = 20;
> On 2015/08/31 05:05:07, Tom Henderson wrote:
> > I am not sure about these statements that are introduced into all legacy
rate
> > controls.  What does it mean practically if the station supports a channel
> width
> > > 20 but the rate control sets it instead to 20?
> 
> There could be an issue in 802.11b, so it should be > 22 or simply >= 40.
> 
> The idea of this statement is to avoid to use legacy rate adaptation for
> 802.11n/ac rates (or at least avoid it to play with different channel widths
and
> guard intervals).
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy.cc
> File src/wifi/model/yans-wifi-phy.cc (right):
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
> src/wifi/model/yans-wifi-phy.cc:229: SetChannelWidth (22);
> no this is different, channel width is 22 MHz in 802.11b and 20 MHz in 802.11g
> (which is a like a copy-paste of 802.11a in the 2.4 GHz band)
> 
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
> src/wifi/model/yans-wifi-phy.cc:255: SetChannelWidth (20);
> On 2015/08/31 05:05:07, Tom Henderson wrote:
> > why not leave this "SetChannelWidth()" out of all ConfigureStandard methods
> that
> > have possibility of variable width, and then set it as attribute in the
> WifiPhy?
> > 
> > This would seem to avoid the need to do the Config::Set() operation after
> > Install() (which is kind of clumsy).
> 
> The problem if we do not do this is that the user need to carefully set the
> channel width.
> Example: Since default is 20 MHz, a user using 802.11b will have to
explicitely
> indicate the channel width of 22.
> This workaround then force the user to configure the channel width only if he
> wants to change from default standard values.

but 802.11b is not one with possibility of variable widths.  I was suggesting to
remove this statement only for 802.11n and ac, where channel width can be
changed.

If I understand correctly, this will only manifest itself in calculation of
noise bandwidth, so do you think we need to document a changed behavior for
802.11b vs. the previous ns-3 release, that 2MHz additional noise bandwidth is
included?

[Tom Henderson, 2015-08-31 12:46:48]

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy.cc
File src/wifi/model/yans-wifi-phy.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:171: "Whether 20MHz, 40MHz, 80 MHz or 160 MHz.",
should document 22 MHz as a possibility

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:1283: m_channelWidth = channelwidth;
how are additional modes added if one later expands channel width using
Config::Set?  I might expect that setting channel width to 40 would trigger the
inclusion of 40MHz modes.

[S. Deronne, 2015-08-31 12:49:43]

On 2015/08/31 12:44:46, Tom Henderson wrote:
> On 2015/08/31 07:04:41, S. Deronne wrote:
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> > File src/wifi/helper/vht-wifi-mac-helper.cc (right):
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> > src/wifi/helper/vht-wifi-mac-helper.cc:45: //who knows what they're doing
can
> > override with explicit attributes.
> > On 2015/08/31 05:05:07, Tom Henderson wrote:
> > > I do not understand this comment
> > 
> > I think this came from Ghada's file.
> > It can be removed I suppose.
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> > File src/wifi/helper/vht-wifi-mac-helper.h (right):
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/helper/vht-wifi-mac-...
> > src/wifi/helper/vht-wifi-mac-helper.h:41: * Create a QosWifiMacHelper that
is
> > used to make life easier when working
> > On 2015/08/31 05:05:07, Tom Henderson wrote:
> > > copy-paste error?
> > 
> > Yes, thanks I will change it.
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
> > File src/wifi/model/cara-wifi-manager.cc (right):
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/cara-wifi-mana...
> > src/wifi/model/cara-wifi-manager.cc:189: channelWidth = 20;
> > On 2015/08/31 05:05:07, Tom Henderson wrote:
> > > I am not sure about these statements that are introduced into all legacy
> rate
> > > controls.  What does it mean practically if the station supports a channel
> > width
> > > > 20 but the rate control sets it instead to 20?
> > 
> > There could be an issue in 802.11b, so it should be > 22 or simply >= 40.
> > 
> > The idea of this statement is to avoid to use legacy rate adaptation for
> > 802.11n/ac rates (or at least avoid it to play with different channel widths
> and
> > guard intervals).
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy.cc
> > File src/wifi/model/yans-wifi-phy.cc (right):
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
> > src/wifi/model/yans-wifi-phy.cc:229: SetChannelWidth (22);
> > no this is different, channel width is 22 MHz in 802.11b and 20 MHz in
802.11g
> > (which is a like a copy-paste of 802.11a in the 2.4 GHz band)
> > 
> >
>
https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
> > src/wifi/model/yans-wifi-phy.cc:255: SetChannelWidth (20);
> > On 2015/08/31 05:05:07, Tom Henderson wrote:
> > > why not leave this "SetChannelWidth()" out of all ConfigureStandard
methods
> > that
> > > have possibility of variable width, and then set it as attribute in the
> > WifiPhy?
> > > 
> > > This would seem to avoid the need to do the Config::Set() operation after
> > > Install() (which is kind of clumsy).
> > 
> > The problem if we do not do this is that the user need to carefully set the
> > channel width.
> > Example: Since default is 20 MHz, a user using 802.11b will have to
> explicitely
> > indicate the channel width of 22.
> > This workaround then force the user to configure the channel width only if
he
> > wants to change from default standard values.
> 
> but 802.11b is not one with possibility of variable widths.  I was suggesting
to
> remove this statement only for 802.11n and ac, where channel width can be
> changed.

This would be ok for 802.11n, for which default channel width is 20 MHz, but not
for ac, for which default width is 80 MHz.
If we do not do this, users will have to change it manually.

> 
> If I understand correctly, this will only manifest itself in calculation of
> noise bandwidth, so do you think we need to document a changed behavior for
> 802.11b vs. the previous ns-3 release, that 2MHz additional noise bandwidth is
> included?

I believe it was included, since it was taken from the mode, where the mode had
the channel width specified (refactoring has removed channel width and data rate
fields in mode generator).

[fnadeem, 2015-08-31 17:11:38]

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
File examples/wireless/ofdm-vht-validation.cc (right):

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
examples/wireless/ofdm-vht-validation.cc:44: modes.push_back ("VhtMcs8");
MCS9 is left out on purpose? Produces expected results when added here.

[Tom Henderson, 2015-09-01 21:53:09]

> > 
> > but 802.11b is not one with possibility of variable widths.  I was
suggesting
> to
> > remove this statement only for 802.11n and ac, where channel width can be
> > changed.
> 
> This would be ok for 802.11n, for which default channel width is 20 MHz, but
not
> for ac, for which default width is 80 MHz.
> If we do not do this, users will have to change it manually.

OK, I withdraw my proposal to remove the SetChannelWidth () statements, although
you might want to consider to move them inside the Configure80211ac() (and
similar) methods.

My lingering concerns are:

- if setting a channel width affects which mode is in the deviceMcsSet, this
logic does not seem to be implemented; how are such higher BW modes enabled or
removed if channel width is later changed?

- we should document WifiHelper::SetStandard that ChannelWidth is now one of
these attributes that is overridden by ConfigureStandard(), and specifically we
should show by example how ChannelWidth should be manipulated for users of
802.11ac and 802.11n.  What I mean by the latter is where you have " // Set
channel width" in vht-wifi-network.cc, you can expand this comment to instead
say "// If channel width different from the 80 MHz 802.11ac default is desired,
users must configure it in this way after Install() has been called.  No
Config::Set() statement is needed if 80 MHz width is desired."

I think it would be nice to put such post-install configuration steps into new
helper methods rather than rely on Config::Set statements, but for the moment,
we need to go with what we have.

[S. Deronne, 2015-09-02 06:02:06]

Tom,

> Le 1 sept. 2015 à 23:53, tomh.org@gmail.com a écrit :
> 
> 
>> >
>> > but 802.11b is not one with possibility of variable widths.  I was
> suggesting
>> to
>> > remove this statement only for 802.11n and ac, where channel width
> can be
>> > changed.
> 
>> This would be ok for 802.11n, for which default channel width is 20
> MHz, but not
>> for ac, for which default width is 80 MHz.
>> If we do not do this, users will have to change it manually.
> 
> OK, I withdraw my proposal to remove the SetChannelWidth () statements,
> although you might want to consider to move them inside the
> Configure80211ac() (and similar) methods.
> 
> My lingering concerns are:
> 
> - if setting a channel width affects which mode is in the deviceMcsSet,
> this logic does not seem to be implemented; how are such higher BW modes
> enabled or removed if channel width is later changed?

I am not sure to get your question. Nothing is removed actually. Once rate
adaptation is implemented (e.g. minstrel), it will decide for a channel width
which is passed in the txvector. Based on that, PHY will pick the corresponding
bitrate.

> 
> - we should document WifiHelper::SetStandard that ChannelWidth is now
> one of these attributes that is overridden by ConfigureStandard(), and
> specifically we should show by example how ChannelWidth should be
> manipulated for users of 802.11ac and 802.11n.  What I mean by the
> latter is where you have " // Set channel width" in vht-wifi-network.cc,
> you can expand this comment to instead say "// If channel width
> different from the 80 MHz 802.11ac default is desired, users must
> configure it in this way after Install() has been called.  No
> Config::Set() statement is needed if 80 MHz width is desired."

Ok.
I had added some docs but not sure it is included in Rietveld.

> 
> I think it would be nice to put such post-install configuration steps
> into new helper methods rather than rely on Config::Set statements, but
> for the moment, we need to go with what we have.

It's my plan to make api more user friendly for aggregation. Such refactoring
could be done at the same time.

> 
> https://codereview.appspot.com/262930043/

Regards,
Sébastien.

[Tom Henderson, 2015-09-02 14:11:03]

> > 
> > - if setting a channel width affects which mode is in the deviceMcsSet,
> > this logic does not seem to be implemented; how are such higher BW modes
> > enabled or removed if channel width is later changed?
> 
> I am not sure to get your question. Nothing is removed actually. Once rate
> adaptation is implemented (e.g. minstrel), it will decide for a channel width
> which is passed in the txvector. Based on that, PHY will pick the
corresponding
> bitrate.
> 

Does setting channel width affect the supported MCS set that are advertised to
the peer?  If it is adjusted later when a beacon has to be sent, then it is
fine, but I was noticing that there was an initial 

  for (uint8_t i = 0; i < 8; i++)
    {
      m_deviceMcsSet.push_back (i);
    }

done in Configure80211n() based on initial defaults, and wondering at what point
in the code the higher MCS values get added (or removed)

[S. Deronne, 2015-09-02 18:00:19]

Tom,

The peers should know whether it supports short GI an which channel width. Mcs
are always the same.

BR,
Sébastien.

> Le 2 sept. 2015 à 16:11, tomh.org@gmail.com a écrit :
> 
> 
>> >
>> > - if setting a channel width affects which mode is in the
> deviceMcsSet,
>> > this logic does not seem to be implemented; how are such higher BW
> modes
>> > enabled or removed if channel width is later changed?
> 
>> I am not sure to get your question. Nothing is removed actually. Once
> rate
>> adaptation is implemented (e.g. minstrel), it will decide for a
> channel width
>> which is passed in the txvector. Based on that, PHY will pick the
> corresponding
>> bitrate.
> 
> 
> Does setting channel width affect the supported MCS set that are
> advertised to the peer?  If it is adjusted later when a beacon has to be
> sent, then it is fine, but I was noticing that there was an initial
> 
>  for (uint8_t i = 0; i < 8; i++)
>    {
>      m_deviceMcsSet.push_back (i);
>    }
> 
> done in Configure80211n() based on initial defaults, and wondering at
> what point in the code the higher MCS values get added (or removed)
> 
> 
> 
> https://codereview.appspot.com/262930043/

[S. Deronne, 2015-09-03 20:04:41]

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
File examples/wireless/ofdm-vht-validation.cc (right):

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
examples/wireless/ofdm-vht-validation.cc:44: modes.push_back ("VhtMcs8");
Yes because MCS9 is not support for 20 MHz channel width

[S. Deronne, 2015-09-03 20:15:29]

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy.cc
File src/wifi/model/yans-wifi-phy.cc (right):

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:171: "Whether 20MHz, 40MHz, 80 MHz or 160 MHz.",
Correct.

https://codereview.appspot.com/262930043/diff/1/src/wifi/model/yans-wifi-phy....
src/wifi/model/yans-wifi-phy.cc:1283: m_channelWidth = channelwidth;
This is handled by the rate adaptation algorithm, which will have to check the
maximum supported channel width and whether short guard interval is supported.
Currently, only constant rate is supported, it selects the highest supported
channel width and it selects the use of a short guard interval when it is
supported.

[S. Deronne, 2015-09-05 10:08:48]

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
File examples/wireless/vht-wifi-network.cc (right):

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
examples/wireless/vht-wifi-network.cc:103: DataRate = StringValue (dataRate);
On 2015/08/31 05:05:07, Tom Henderson wrote:
> Why not avoid this C++ string handling in user programs and provide a helper:
> e.g. 
> 
> DataRate VhtWifiMacHelper::DataRateForMcs (int mcs)

Done.

[S. Deronne, 2015-09-05 11:35:22]

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
File examples/wireless/vht-wifi-network.cc (right):

https://codereview.appspot.com/262930043/diff/1/examples/wireless/vht-wifi-ne...
examples/wireless/vht-wifi-network.cc:28: //This is a simple example of an IEEE
802.11ac Wi-Fi network.
On 2015/08/31 05:05:07, Tom Henderson wrote:
> Please elaborate more what this example demonstrates and what kind of output
it
> produces.

Done.

[S. Deronne, 2015-09-05 13:44:10]

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
File examples/wireless/ofdm-vht-validation.cc (right):

https://codereview.appspot.com/262930043/diff/1/examples/wireless/ofdm-vht-va...
examples/wireless/ofdm-vht-validation.cc:28: 
On 2015/08/31 05:05:07, Tom Henderson wrote:
> what exactly is validated?  Please add comment.  Or should we move this to a
> test suite?

Done.