802.11ax initial support

802.11ax initial support

[Rediet, 2017-01-12 11:18:02]

Hello Sebastien,

Sorry for the late review, but here are some minor comments concerning model/*
files.

BR,

Rediet

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
File src/wifi/model/nist-error-rate-model.cc (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
src/wifi/model/nist-error-rate-model.cc:102: double ber = 31.0 / 160.0 * 0.5 *
erfc (z);
Taking M=1024 and k=10,
(1-1/Sqrt(M)) * 4/k = 31/32 * 2/5 = 31/80
So I think that it should be rather:
double ber = 31.0 / 80.0 * 0.5 * erfc (z);

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

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc#ne...
src/wifi/model/wifi-phy.cc:1704: case WIFI_PREAMBLE_HE:
According to SFD, the mandatory HE-LTF modes are 2xLTF (6.4µs without GI) and
4xLTF (12.8µs without GI). If we also take into account the mandatory
combinations, 2xLTF+0.8µs, 2xLTF+1.6µs, and 4xLTF+3.2µs, along with the fact
that HE-LTF and data use same GI, it would lead to the following durations:
7.2µs, 8µs, and 16µs.
1xLTF+0.8µs (leading to 4µs) is an optional mode. So is it worth using it here?
I would rather go for 8µs or 16µs.

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc#ne...
src/wifi/model/wifi-phy.cc:2227: //if short GI data rate is used then symbol
duration is 3.6us else symbol duration is 4us
Comment to update with HE Data field durations

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble.h
File src/wifi/model/wifi-preamble.h (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble....
src/wifi/model/wifi-preamble.h:37: WIFI_PREAMBLE_HE,
The SFD addresses 3 different preamble formats:
- SU format and Trigger-based UL
- MU format
- Extended range SU format
Why not then go for 4 PPDU formats (separating SU and Trigger-based UL) instead
of just one? Is it for simplicity of implementation?

[S. Deronne, 2017-01-12 14:56:41]

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
File src/wifi/model/nist-error-rate-model.cc (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
src/wifi/model/nist-error-rate-model.cc:102: double ber = 31.0 / 160.0 * 0.5 *
erfc (z);
On 2017/01/12 11:18:01, rediet wrote:
> Taking M=1024 and k=10,
> (1-1/Sqrt(M)) * 4/k = 31/32 * 2/5 = 31/80
> So I think that it should be rather:
> double ber = 31.0 / 80.0 * 0.5 * erfc (z);

I found this already calculated somewhere, I will double check

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

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc#ne...
src/wifi/model/wifi-phy.cc:1704: case WIFI_PREAMBLE_HE:
On 2017/01/12 11:18:01, rediet wrote:
> According to SFD, the mandatory HE-LTF modes are 2xLTF (6.4µs without GI) and
> 4xLTF (12.8µs without GI). If we also take into account the mandatory
> combinations, 2xLTF+0.8µs, 2xLTF+1.6µs, and 4xLTF+3.2µs, along with the fact
> that HE-LTF and data use same GI, it would lead to the following durations:
> 7.2µs, 8µs, and 16µs.
> 1xLTF+0.8µs (leading to 4µs) is an optional mode. So is it worth using it
here?
> I would rather go for 8µs or 16µs.

I did not really focused on those details for the first phase since I guess
standard might still change a bit. I will check again the standard and maybe go
for 8 or 16 iso 4.

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc#ne...
src/wifi/model/wifi-phy.cc:2227: //if short GI data rate is used then symbol
duration is 3.6us else symbol duration is 4us
On 2017/01/12 11:18:01, rediet wrote:
> Comment to update with HE Data field durations

Indeed, thanks

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble.h
File src/wifi/model/wifi-preamble.h (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble....
src/wifi/model/wifi-preamble.h:37: WIFI_PREAMBLE_HE,
On 2017/01/12 11:18:01, rediet wrote:
> The SFD addresses 3 different preamble formats:
> - SU format and Trigger-based UL
> - MU format
> - Extended range SU format
> Why not then go for 4 PPDU formats (separating SU and Trigger-based UL)
instead
> of just one? Is it for simplicity of implementation?

This first phase only supports SU format, so I wanted to have one and extend
later once we support more than one. If it is prefer to have 4 of them directly,
then we can go for it, but using only SU case in our code.

[Rediet, 2017-01-12 17:08:17]

On 2017/01/12 14:56:41, S. Deronne wrote:
>
https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
> File src/wifi/model/nist-error-rate-model.cc (right):
> 
>
https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
> src/wifi/model/nist-error-rate-model.cc:102: double ber = 31.0 / 160.0 * 0.5 *
> erfc (z);
> On 2017/01/12 11:18:01, rediet wrote:
> > Taking M=1024 and k=10,
> > (1-1/Sqrt(M)) * 4/k = 31/32 * 2/5 = 31/80
> > So I think that it should be rather:
> > double ber = 31.0 / 80.0 * 0.5 * erfc (z);
> 
> I found this already calculated somewhere, I will double check
> 
> https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc
> File src/wifi/model/wifi-phy.cc (right):
> 
>
https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc#ne...
> src/wifi/model/wifi-phy.cc:1704: case WIFI_PREAMBLE_HE:
> On 2017/01/12 11:18:01, rediet wrote:
> > According to SFD, the mandatory HE-LTF modes are 2xLTF (6.4µs without GI)
and
> > 4xLTF (12.8µs without GI). If we also take into account the mandatory
> > combinations, 2xLTF+0.8µs, 2xLTF+1.6µs, and 4xLTF+3.2µs, along with the fact
> > that HE-LTF and data use same GI, it would lead to the following durations:
> > 7.2µs, 8µs, and 16µs.
> > 1xLTF+0.8µs (leading to 4µs) is an optional mode. So is it worth using it
> here?
> > I would rather go for 8µs or 16µs.
> 
> I did not really focused on those details for the first phase since I guess
> standard might still change a bit. I will check again the standard and maybe
go
> for 8 or 16 iso 4.
> 
>
https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc#ne...
> src/wifi/model/wifi-phy.cc:2227: //if short GI data rate is used then symbol
> duration is 3.6us else symbol duration is 4us
> On 2017/01/12 11:18:01, rediet wrote:
> > Comment to update with HE Data field durations
> 
> Indeed, thanks
> 
> https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble.h
> File src/wifi/model/wifi-preamble.h (right):
> 
>
https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble....
> src/wifi/model/wifi-preamble.h:37: WIFI_PREAMBLE_HE,
> On 2017/01/12 11:18:01, rediet wrote:
> > The SFD addresses 3 different preamble formats:
> > - SU format and Trigger-based UL
> > - MU format
> > - Extended range SU format
> > Why not then go for 4 PPDU formats (separating SU and Trigger-based UL)
> instead
> > of just one? Is it for simplicity of implementation?
> 
> This first phase only supports SU format, so I wanted to have one and extend
> later once we support more than one. If it is prefer to have 4 of them
directly,
> then we can go for it, but using only SU case in our code.

Whichever option is OK for me; you know what the best one is. It was just so as
not to forget remaining formats (including extended range SU which falls within
the current scope).

[S. Deronne, 2017-01-15 17:23:25]

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
File src/wifi/model/nist-error-rate-model.cc (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
src/wifi/model/nist-error-rate-model.cc:102: double ber = 31.0 / 160.0 * 0.5 *
erfc (z);
On 2017/01/12 11:18:01, rediet wrote:
> Taking M=1024 and k=10,
> (1-1/Sqrt(M)) * 4/k = 31/32 * 2/5 = 31/80
> So I think that it should be rather:
> double ber = 31.0 / 80.0 * 0.5 * erfc (z);

You forgot the 1/2 factor in your computation.
Note that calculations are the same as those provided in
http://educypedia.karadimov.info/library/QAM.pdf

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble.h
File src/wifi/model/wifi-preamble.h (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-preamble....
src/wifi/model/wifi-preamble.h:37: WIFI_PREAMBLE_HE,
I will change this to include the 4 preambles already, I think it is the best
solution. Thanks for your suggestion.

[Rediet, 2017-01-16 08:48:49]

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
File src/wifi/model/nist-error-rate-model.cc (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
src/wifi/model/nist-error-rate-model.cc:102: double ber = 31.0 / 160.0 * 0.5 *
erfc (z);
On 2017/01/15 17:23:25, S. Deronne wrote:
> On 2017/01/12 11:18:01, rediet wrote:
> > Taking M=1024 and k=10,
> > (1-1/Sqrt(M)) * 4/k = 31/32 * 2/5 = 31/80
> > So I think that it should be rather:
> > double ber = 31.0 / 80.0 * 0.5 * erfc (z);
> 
> You forgot the 1/2 factor in your computation.
> Note that calculations are the same as those provided in
> http://educypedia.karadimov.info/library/QAM.pdf

OK, sorry for the false alert then.
Done.

[S. Deronne, 2017-01-16 09:47:19]

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
File src/wifi/model/nist-error-rate-model.cc (right):

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/nist-error-rat...
src/wifi/model/nist-error-rate-model.cc:102: double ber = 31.0 / 160.0 * 0.5 *
erfc (z);
No problem, it is good you did check this

[S. Deronne, 2017-01-18 21:13:55]

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

https://codereview.appspot.com/315320043/diff/1/src/wifi/model/wifi-phy.cc#ne...
src/wifi/model/wifi-phy.cc:1704: case WIFI_PREAMBLE_HE:
I will go for 8 in this first implementation, could be extended later.

[Tom Henderson, 2017-01-21 16:38:26]

I'm fine with the patch.  There are a lot of lte files that I assume are there
by mistake.

My main concern is that we should more prominently disclaim that this model does
not contain any of the high-density improvements that are touted for 11ax,
because I can envision researchers starting to publish high-density scenarios
with this model, labelled '11ax'.

My other concern/question is whether the error rate models have been confirmed
by any cross-checking with e.g. TGax curves or link sim results (if there are
any)?    In either case, can we document in the Sphinx?  (e.g. either "The error
rate models are extended from OFDM models originally done for 11a and have not
been cross-checked against link sim results."  or "The error rate models have
been cross-checked against [insert reference]."

https://codereview.appspot.com/315320043/diff/40001/examples/wireless/he-wifi...
File examples/wireless/he-wifi-network.cc (right):

https://codereview.appspot.com/315320043/diff/40001/examples/wireless/he-wifi...
examples/wireless/he-wifi-network.cc:29: // It ouputs the UDP or TCP goodput for
every HE MCS value, which depends on the MCS value (0 to 11),
outputs

https://codereview.appspot.com/315320043/diff/40001/examples/wireless/ofdm-he...
File examples/wireless/ofdm-he-validation.cc (right):

https://codereview.appspot.com/315320043/diff/40001/examples/wireless/ofdm-he...
examples/wireless/ofdm-he-validation.cc:21: // It ouputs plots of the Frame
Success Rate versus the Signal-to-noise ratio for
outputs

https://codereview.appspot.com/315320043/diff/40001/src/wifi/doc/source/wifi-...
File src/wifi/doc/source/wifi-design.rst (right):

https://codereview.appspot.com/315320043/diff/40001/src/wifi/doc/source/wifi-...
src/wifi/doc/source/wifi-design.rst:169: * 802.11ac/ax MU-MIMO is not supported,
and no more than 4 antennas can be configured
add '* 802.11ax MU-OFDMA is not supported'

https://codereview.appspot.com/315320043/diff/40001/src/wifi/model/wifi-utils.cc
File src/wifi/model/wifi-utils.cc (right):

https://codereview.appspot.com/315320043/diff/40001/src/wifi/model/wifi-utils...
src/wifi/model/wifi-utils.cc:53: ConvertGuardIntervalToNanoSeconds (WifiMode
mode, bool htShortGuardInterval, Time heGuardInterval)
I would have maybe expected that the guardInterval native formats in e.g.
WifiTxVector would be of type ns3::Time, which would remove the need for this
kind of helper method?  I don't care strongly whether you change this, I just
mention it as a possible alignment with convention in rest of codebase (to store
time values as ns3::Time).

[S. Deronne, 2017-01-22 20:47:58]

On 2017/01/21 16:38:26, Tom Henderson wrote:
> I'm fine with the patch.  There are a lot of lte files that I assume are there
> by mistake.

Yes sorry, I think something went wrong when using upload.py.

> 
> My main concern is that we should more prominently disclaim that this model
does
> not contain any of the high-density improvements that are touted for 11ax,
> because I can envision researchers starting to publish high-density scenarios
> with this model, labelled '11ax'.

I will add a comment in the doc.

> 
> My other concern/question is whether the error rate models have been confirmed
> by any cross-checking with e.g. TGax curves or link sim results (if there are
> any)?    In either case, can we document in the Sphinx?  (e.g. either "The
error
> rate models are extended from OFDM models originally done for 11a and have not
> been cross-checked against link sim results."  or "The error rate models have
> been cross-checked against [insert reference]."
> 

It was not compared yet, but I double checked whether outputs sound correct. 
In which document do you want to see this notified?

>
https://codereview.appspot.com/315320043/diff/40001/examples/wireless/he-wifi...
> File examples/wireless/he-wifi-network.cc (right):
> 
>
https://codereview.appspot.com/315320043/diff/40001/examples/wireless/he-wifi...
> examples/wireless/he-wifi-network.cc:29: // It ouputs the UDP or TCP goodput
for
> every HE MCS value, which depends on the MCS value (0 to 11),
> outputs
> 
>
https://codereview.appspot.com/315320043/diff/40001/examples/wireless/ofdm-he...
> File examples/wireless/ofdm-he-validation.cc (right):
> 
>
https://codereview.appspot.com/315320043/diff/40001/examples/wireless/ofdm-he...
> examples/wireless/ofdm-he-validation.cc:21: // It ouputs plots of the Frame
> Success Rate versus the Signal-to-noise ratio for
> outputs
> 
>
https://codereview.appspot.com/315320043/diff/40001/src/wifi/doc/source/wifi-...
> File src/wifi/doc/source/wifi-design.rst (right):
> 
>
https://codereview.appspot.com/315320043/diff/40001/src/wifi/doc/source/wifi-...
> src/wifi/doc/source/wifi-design.rst:169: * 802.11ac/ax MU-MIMO is not
supported,
> and no more than 4 antennas can be configured
> add '* 802.11ax MU-OFDMA is not supported'
> 
>
https://codereview.appspot.com/315320043/diff/40001/src/wifi/model/wifi-utils.cc
> File src/wifi/model/wifi-utils.cc (right):
> 
>
https://codereview.appspot.com/315320043/diff/40001/src/wifi/model/wifi-utils...
> src/wifi/model/wifi-utils.cc:53: ConvertGuardIntervalToNanoSeconds (WifiMode
> mode, bool htShortGuardInterval, Time heGuardInterval)
> I would have maybe expected that the guardInterval native formats in e.g.
> WifiTxVector would be of type ns3::Time, which would remove the need for this
> kind of helper method?  I don't care strongly whether you change this, I just
> mention it as a possible alignment with convention in rest of codebase (to
store
> time values as ns3::Time).

I will update a new patch set tomorrow

[S. Deronne, 2017-01-22 20:48:08]

https://codereview.appspot.com/315320043/diff/40001/src/wifi/doc/source/wifi-...
File src/wifi/doc/source/wifi-design.rst (right):

https://codereview.appspot.com/315320043/diff/40001/src/wifi/doc/source/wifi-...
src/wifi/doc/source/wifi-design.rst:169: * 802.11ac/ax MU-MIMO is not supported,
and no more than 4 antennas can be configured
On 2017/01/21 16:38:26, Tom Henderson wrote:
> add '* 802.11ax MU-OFDMA is not supported'

OK

[Tom Henderson, 2017-01-22 22:51:44]

> It was not compared yet, but I double checked whether outputs sound correct. 
> In which document do you want to see this notified?

There is an Error Model section of the testing documentation (wifi-testing.rst)
that can be updated.

[S. Deronne, 2017-01-23 20:17:01]

On 2017/01/22 22:51:44, Tom Henderson wrote:
> > It was not compared yet, but I double checked whether outputs sound correct.

> > In which document do you want to see this notified?
> 
> There is an Error Model section of the testing documentation
(wifi-testing.rst)
> that can be updated.

Then should we not also include the curves for 802.11n and 802.11ac?

[S. Deronne, 2017-01-25 19:17:29]

Patch set updated:
- handled Tom's comments, except the error model section, which is unclear why
we would do this for 802.11ax and not for 802.11n/ac then.
- removed lte files (another commit was pushed together with the patch set)

[Tom Henderson, 2017-01-25 23:28:27]

On 2017/01/25 19:17:29, S. Deronne wrote:
> Patch set updated:
> - handled Tom's comments, except the error model section, which is unclear why
> we would do this for 802.11ax and not for 802.11n/ac then.

I would like to update for all.  However, I don't mean to block this merge with
a lot of work, so I just suggest to state what has been checked or not checked. 
We can do a more thorough job updating this validation at a later date.

If we look at this section:

https://www.nsnam.org/docs/release/3.26/models/html/wifi-testing.html#error-m...

I think the following statements can be appended for now; please change if you
actually do have validation results to state.

"The OFDM error rate models initially developed for 802.11a are reused for
802.11n and 802.11ac.  However, the performance has not been validated against
TGn curves or experimentally.  Curves for MCS 8 and 9 (802.11ac) and 10 and 11
(802.11ax) have not yet been validated experimentally or with link simulations."

[S. Deronne, 2017-01-28 18:42:13]

On 2017/01/25 23:28:27, Tom Henderson wrote:
> On 2017/01/25 19:17:29, S. Deronne wrote:
> > Patch set updated:
> > - handled Tom's comments, except the error model section, which is unclear
why
> > we would do this for 802.11ax and not for 802.11n/ac then.
> 
> I would like to update for all.  However, I don't mean to block this merge
with
> a lot of work, so I just suggest to state what has been checked or not
checked. 
> We can do a more thorough job updating this validation at a later date.
> 
> If we look at this section:
> 
>
https://www.nsnam.org/docs/release/3.26/models/html/wifi-testing.html#error-m...
> 
> I think the following statements can be appended for now; please change if you
> actually do have validation results to state.
> 
> "The OFDM error rate models initially developed for 802.11a are reused for
> 802.11n and 802.11ac.  However, the performance has not been validated against
> TGn curves or experimentally.  Curves for MCS 8 and 9 (802.11ac) and 10 and 11
> (802.11ax) have not yet been validated experimentally or with link
simulations."

Tom, thanks.
Then I will handle those improvements a bit later.