Bug 3019

Already sent offline to Tom, I'd like some comments on this.

Main comments:

1) I commented on another patch that we may have a proliferation of setters and getters in HeConfiguration (and other configuration objects) that are redundant with Get/SetAttribute.  Consider to align with decision taken on that other bug.

2) there are a number of Vht and He headers that aren't really used (to have three separate serialize/deserialize calls instead of one).  I suggest to just use one per standard for now unless there is an explicit need for multiple.

3) For the remaining WifiPhyTag, is MpduType still needed?  This seems out of place because it is a MAC level issue, while the other two (preamble type and modulation) are related to PHY decoding.

Minor comments:

1) in LSigHeader::SetRate(), it comments:

  /* Here is the binary representation for a given rate:
   * 6 Mbit/s: 1101
   ...

but every value used is hex and not binary.

2) why is there a wave test case commented out; should it be fixed?

3) there is a check:

  if (!txVector.GetModeInitialized ())
    {
        NS_LOG_DEBUG ("drop packet because of unsupported RX mode");
    }

should it say uninitialized WifiTxVector rather than unsupported RX mode?

(In reply to Tom Henderson from comment #2)
> Main comments:
> 
> 1) I commented on another patch that we may have a proliferation of setters
> and getters in HeConfiguration (and other configuration objects) that are
> redundant with Get/SetAttribute.  Consider to align with decision taken on
> that other bug.

I find that GetFoo () looks more user friendly than:

UintegerValue foo;
heConfiguration->GetAttribute ("Foo", foo);
uint8_t _foo = foo.Get ();

> 
> 2) there are a number of Vht and He headers that aren't really used (to have
> three separate serialize/deserialize calls instead of one).  I suggest to
> just use one per standard for now unless there is an explicit need for
> multiple.
> 

OK, I agree.

> 3) For the remaining WifiPhyTag, is MpduType still needed?  This seems out
> of place because it is a MAC level issue, while the other two (preamble type
> and modulation) are related to PHY decoding.

I agree, I will have a look whether there is a way to avoid this.

> 
> Minor comments:
> 
> 1) in LSigHeader::SetRate(), it comments:
> 
>   /* Here is the binary representation for a given rate:
>    * 6 Mbit/s: 1101
>    ...
> 
> but every value used is hex and not binary.

OK, I will use binary notation.

> 
> 2) why is there a wave test case commented out; should it be fixed?

I actually could not understand why this condition was suddenly not OK, so I commented out for now.

> 
> 3) there is a check:
> 
>   if (!txVector.GetModeInitialized ())
>     {
>         NS_LOG_DEBUG ("drop packet because of unsupported RX mode");
>     }
> 
> should it say uninitialized WifiTxVector rather than unsupported RX mode?

This is correct, but maybe I should have a comment to explain why. Above this line, we reconstruct the TX vector, and if the mode transported in the header is not supported by the station, SetMode () will not be called.

Also, would we change the name of the file to wifi-phy-header since PLCP is apparently a deprecated naming?

(In reply to sebastien.deronne from comment #3)
> (In reply to Tom Henderson from comment #2)
> > Main comments:
> > 
> > 1) I commented on another patch that we may have a proliferation of setters
> > and getters in HeConfiguration (and other configuration objects) that are
> > redundant with Get/SetAttribute.  Consider to align with decision taken on
> > that other bug.
> 
> I find that GetFoo () looks more user friendly than:
> 
> UintegerValue foo;
> heConfiguration->GetAttribute ("Foo", foo);
> uint8_t _foo = foo.Get ();

OK, I responded in another bug issue about this point.

I agree the built-in is more clumsy syntax; however, I just would like to avoid setters and getters that no one is using, because the API and Doxygen swells.

> > 
> > 3) there is a check:
> > 
> >   if (!txVector.GetModeInitialized ())
> >     {
> >         NS_LOG_DEBUG ("drop packet because of unsupported RX mode");
> >     }
> > 
> > should it say uninitialized WifiTxVector rather than unsupported RX mode?
> 
> This is correct, but maybe I should have a comment to explain why. Above
> this line, we reconstruct the TX vector, and if the mode transported in the
> header is not supported by the station, SetMode () will not be called.

OK

(In reply to sebastien.deronne from comment #4)
> Also, would we change the name of the file to wifi-phy-header since PLCP is
> apparently a deprecated naming?

OK

 
> 3) For the remaining WifiPhyTag, is MpduType still needed?  This seems out
> of place because it is a MAC level issue, while the other two (preamble type
> and modulation) are related to PHY decoding.

I managed to prepare a solution but I cannot find in 11ax standard that there is a LENGTH field in the HE-SIG. Using 11n/ac length fields in SIG headers, I managed to have this working.
Any idea whether there is a LENGTH field in HE-SIG-A or HE-SIG-B?

(In reply to sebastien.deronne from comment #7)
>  
> > 3) For the remaining WifiPhyTag, is MpduType still needed?  This seems out
> > of place because it is a MAC level issue, while the other two (preamble type
> > and modulation) are related to PHY decoding.
> 
> I managed to prepare a solution but I cannot find in 11ax standard that
> there is a LENGTH field in the HE-SIG. Using 11n/ac length fields in SIG
> headers, I managed to have this working.
> Any idea whether there is a LENGTH field in HE-SIG-A or HE-SIG-B?

Sorry, I am not following; how does a possible length in HE-SIG field relate to MpduType?

(In reply to Tom Henderson from comment #8)
> (In reply to sebastien.deronne from comment #7)
> >  
> > > 3) For the remaining WifiPhyTag, is MpduType still needed?  This seems out
> > > of place because it is a MAC level issue, while the other two (preamble type
> > > and modulation) are related to PHY decoding.
> > 
> > I managed to prepare a solution but I cannot find in 11ax standard that
> > there is a LENGTH field in the HE-SIG. Using 11n/ac length fields in SIG
> > headers, I managed to have this working.
> > Any idea whether there is a LENGTH field in HE-SIG-A or HE-SIG-B?
> 
> Sorry, I am not following; how does a possible length in HE-SIG field relate
> to MpduType?

Based on the total length of the PSDU indicated in the SIG, the receiver can know when the last MPDU is received.

> > 
> > Sorry, I am not following; how does a possible length in HE-SIG field relate
> > to MpduType?
> 
> Based on the total length of the PSDU indicated in the SIG, the receiver can
> know when the last MPDU is received.

I guess perhaps L-SIG length may be sufficient; maybe someone else can clarify.

(In reply to Tom Henderson from comment #10)
> > > 
> > > Sorry, I am not following; how does a possible length in HE-SIG field relate
> > > to MpduType?
> > 
> > Based on the total length of the PSDU indicated in the SIG, the receiver can
> > know when the last MPDU is received.
> 
> I guess perhaps L-SIG length may be sufficient; maybe someone else can
> clarify.

If my understanding is correct, I would say that it'll be the same logic as 11n/ac (for SU). The L-SIG length is used to signal the number of symbols used by the HE-DATA.
If we consider that no packet extension is needed (i.e. HE device can process process the received data and reply within SIFS, without the need for dummy post-pended bits),
TXTIME = T_L-Preamble + T_HE-Preamble + T_HE-Data, with T_HE-Data = (12.8us + T_GI) * N_symbols
In addition, for HE PPDUs, L-SIG_length should not be a multiple of 3, so as to distinguish from 11ac and avoid false positives.
L-SIG_length = ceil ((TXTIME - T_L-Preamble) / 4) * 3 - 3 - m, with m = 1 (for SU) and 2 (for MU and Extended-SU)
Note 1: multiply by 3 b/c 6 Mbps data rate in L-SIG
Note 2: remove 3 b/c service + tail
Note 3: since we assume that there is no packet extension, there is ambiguity in the number of useful symbols (and thus no disambiguity bit needed when determining N_symbols).

(In reply to sebastien.deronne from comment #1)
> Already sent offline to Tom, I'd like some comments on this.

1) Why is there a need to exclude HT mixed-mode transmissions during transmission/reception of OFDM legacy preamble?
((modulation != WIFI_MOD_CLASS_HT) || (preamble != WIFI_PREAMBLE_HT_GF))
Normally 11n MM should include it. Shouldn't it rather be && in the condition above?

2) I understand the logic but it seems quite odd to always have SIGBs (for VHT and HE) even in SU mode? Is there a way to send only the headers we need (maybe through the WifiPhyTag)?

(In reply to Rediet from comment #12)
> (In reply to sebastien.deronne from comment #1)
> > Already sent offline to Tom, I'd like some comments on this.
> 
> 1) Why is there a need to exclude HT mixed-mode transmissions during
> transmission/reception of OFDM legacy preamble?
> ((modulation != WIFI_MOD_CLASS_HT) || (preamble != WIFI_PREAMBLE_HT_GF))
> Normally 11n MM should include it. Shouldn't it rather be && in the
> condition above?

HT GF should not include it, so this would also be valid but similar:
((modulation == WIFI_MOD_CLASS_HT) && (preamble == WIFI_PREAMBLE_HT_GF))

> 
> 2) I understand the logic but it seems quite odd to always have SIGBs (for
> VHT and HE) even in SU mode? Is there a way to send only the headers we need
> (maybe through the WifiPhyTag)?

I merged all SIGs per standard as requested by Tom in a previous comment, is this what you mean?

(In reply to Rediet from comment #11)
> (In reply to Tom Henderson from comment #10)
> > > > 
> > > > Sorry, I am not following; how does a possible length in HE-SIG field relate
> > > > to MpduType?
> > > 
> > > Based on the total length of the PSDU indicated in the SIG, the receiver can
> > > know when the last MPDU is received.
> > 
> > I guess perhaps L-SIG length may be sufficient; maybe someone else can
> > clarify.
> 
> If my understanding is correct, I would say that it'll be the same logic as
> 11n/ac (for SU). The L-SIG length is used to signal the number of symbols
> used by the HE-DATA.
> If we consider that no packet extension is needed (i.e. HE device can
> process process the received data and reply within SIFS, without the need
> for dummy post-pended bits),
> TXTIME = T_L-Preamble + T_HE-Preamble + T_HE-Data, with T_HE-Data = (12.8us
> + T_GI) * N_symbols
> In addition, for HE PPDUs, L-SIG_length should not be a multiple of 3, so as
> to distinguish from 11ac and avoid false positives.
> L-SIG_length = ceil ((TXTIME - T_L-Preamble) / 4) * 3 - 3 - m, with m = 1
> (for SU) and 2 (for MU and Extended-SU)
> Note 1: multiply by 3 b/c 6 Mbps data rate in L-SIG
> Note 2: remove 3 b/c service + tail
> Note 3: since we assume that there is no packet extension, there is
> ambiguity in the number of useful symbols (and thus no disambiguity bit
> needed when determining N_symbols).

Then for me it's not clear why there is a HT length and VHT length field for 11n/ac.

Rediet, what is the purpose of the HT and VHT length fields?

Also, with your definition it seems that the L-SIG_length field is expressed in time units instead of bytes. Is this correct?

(In reply to sebastien.deronne from comment #13)
> (In reply to Rediet from comment #12)
> > 
> > 1) Why is there a need to exclude HT mixed-mode transmissions during
> > transmission/reception of OFDM legacy preamble?
> > ((modulation != WIFI_MOD_CLASS_HT) || (preamble != WIFI_PREAMBLE_HT_GF))
> > Normally 11n MM should include it. Shouldn't it rather be && in the
> > condition above?
> 
> HT GF should not include it, so this would also be valid but similar:
> ((modulation == WIFI_MOD_CLASS_HT) && (preamble == WIFI_PREAMBLE_HT_GF))
> 
OK. It's clear now.

> > 
> > 2) I understand the logic but it seems quite odd to always have SIGBs (for
> > VHT and HE) even in SU mode? Is there a way to send only the headers we need
> > (maybe through the WifiPhyTag)?
> 
> I merged all SIGs per standard as requested by Tom in a previous comment, is
> this what you mean?

It can help but it would still mean that a VHT/HE SIG-B field would always be present irrespective of whether the PPDU is SU or MU. This would be quite confusing for the end user.
I was rather saying that the presence of:
- VHT-SIG-B would be conditioned by the value of the group ID field in VHT-SIG-A1 (different from 0 or 63)
- HE-SIG-B would be conditioned by m (equal to 2, with m being L-SIG length modulo 3) and modulation used for HE-SIG-A2 (BPSK)
In the first case, we could only rely on the information present within the SIG header, but in the second an external information, probably conveyed through the tag, is needed.

(In reply to sebastien.deronne from comment #15)
> Rediet, what is the purpose of the HT and VHT length fields?

An additional length field was introduced in the HT-SIG b/c the L-SIG_length field was used to set the duration of the packet (with L-SIG_rate @6Mbps). This HT-SIG_length gives the true length of the A-MPDU.

The logic changed a bit in the following standards, since such use was relatively redundant for SU.
The length field in VHT is found in VHT-SIG-B and only concerns MU transmissions. This way the receiving station can easily obtain the real duration of its A-MPDU, when padding (using delimiters) is used to align all PSDUs.

> 
> Also, with your definition it seems that the L-SIG_length field is expressed
> in time units instead of bytes. Is this correct?

The 4 in the provided equation is actually 4 us. Forgot to mention that (important) detail.
L-SIG_length = ceil ((TXTIME - T_L-Preamble) / 4 us) * 3 - 3 - m, with m = 1 (for SU) and 2 (for MU and Extended-SU)

Rediet, my understanding was that there were at least always one SIG-B present.
In the current code, we take into account one SIG-B as we do not support MU.
So, is this actually totally wrong?

From what I read it seems you are right. My proposal would then be to:
1/ Remove SIG-B as we do not support MU
2/ Prepare an item to add VHT/HE SIG-B support to prepare MU transmissions.

Doing this we can speedup remaining work we currently have and postpone to few weeks SIB-B support.

(In reply to Rediet from comment #17)
> (In reply to sebastien.deronne from comment #15)
> > Rediet, what is the purpose of the HT and VHT length fields?
> 
> An additional length field was introduced in the HT-SIG b/c the L-SIG_length
> field was used to set the duration of the packet (with L-SIG_rate @6Mbps).
> This HT-SIG_length gives the true length of the A-MPDU.
> 
> The logic changed a bit in the following standards, since such use was
> relatively redundant for SU.
> The length field in VHT is found in VHT-SIG-B and only concerns MU
> transmissions. This way the receiving station can easily obtain the real
> duration of its A-MPDU, when padding (using delimiters) is used to align all
> PSDUs.
> 

But then the L-SIG would need much more than 12 bits to express duration of a A-MPDU, and I see in the 11n standard the size cannot exceed 4095 octets.
So I am wondering what is sent in L-SIG for A-MPDU in 11n? Or this is the reason they introduced HT_LENGTH, so actually LENGTH is a messy value.

> > 
> > Also, with your definition it seems that the L-SIG_length field is expressed
> > in time units instead of bytes. Is this correct?
> 
> The 4 in the provided equation is actually 4 us. Forgot to mention that
> (important) detail.
> L-SIG_length = ceil ((TXTIME - T_L-Preamble) / 4 us) * 3 - 3 - m, with m = 1
> (for SU) and 2 (for MU and Extended-SU)

OK, but in 11ax the symbol duration is extended compared to 11n/ac.

(In reply to sebastien.deronne from comment #18)
> Rediet, my understanding was that there were at least always one SIG-B
> present.
> In the current code, we take into account one SIG-B as we do not support MU.
> So, is this actually totally wrong?
Yes, SIG-B is relevant for MU only. 

> From what I read it seems you are right. My proposal would then be to:
> 1/ Remove SIG-B as we do not support MU
> 2/ Prepare an item to add VHT/HE SIG-B support to prepare MU transmissions.
> 
> Doing this we can speedup remaining work we currently have and postpone to
> few weeks SIB-B support.
In phase.

(In reply to sebastien.deronne from comment #19)
> (In reply to Rediet from comment #17)
> > (In reply to sebastien.deronne from comment #15)
> > > Rediet, what is the purpose of the HT and VHT length fields?
> > 
> > An additional length field was introduced in the HT-SIG b/c the L-SIG_length
> > field was used to set the duration of the packet (with L-SIG_rate @6Mbps).
> > This HT-SIG_length gives the true length of the A-MPDU.
> > 
> > The logic changed a bit in the following standards, since such use was
> > relatively redundant for SU.
> > The length field in VHT is found in VHT-SIG-B and only concerns MU
> > transmissions. This way the receiving station can easily obtain the real
> > duration of its A-MPDU, when padding (using delimiters) is used to align all
> > PSDUs.
> > 
> 
> But then the L-SIG would need much more than 12 bits to express duration of
> a A-MPDU, and I see in the 11n standard the size cannot exceed 4095 octets.
> So I am wondering what is sent in L-SIG for A-MPDU in 11n? Or this is the
> reason they introduced HT_LENGTH, so actually LENGTH is a messy value.
I have to admit that it's an odd logic but 11n/ac/ax reuse L-SIG_LENGTH only for defining the PSDU's duration. The advantage is that legacy stations (11a for 11n/ac/ax, but also 11n for 11ac/ax and so on) will all be able to deduce PPDU duration.
Considering that L-SIG_RATE field is set to 6 Mbps, L-SIG_LENGTH can signal a max duration of 5.460 ms, irrespective of the actual max A-MPDU size. 

> > > 
> > > Also, with your definition it seems that the L-SIG_length field is expressed
> > > in time units instead of bytes. Is this correct?
> > 
> > The 4 in the provided equation is actually 4 us. Forgot to mention that
> > (important) detail.
> > L-SIG_length = ceil ((TXTIME - T_L-Preamble) / 4 us) * 3 - 3 - m, with m = 1
> > (for SU) and 2 (for MU and Extended-SU)
> 
> OK, but in 11ax the symbol duration is extended compared to 11n/ac.
Since the duration is determined using the L-SIG_LENGTH and L-SIG_RATE, we should assume 11a OFDM symbol duration for this part.
The actual number of HE data symbols is determined using the 11ax symbol duration (see comment 11).

(In reply to Rediet from comment #20)
> (In reply to sebastien.deronne from comment #18)
> > Rediet, my understanding was that there were at least always one SIG-B
> > present.
> > In the current code, we take into account one SIG-B as we do not support MU.
> > So, is this actually totally wrong?
> Yes, SIG-B is relevant for MU only. 
> 
> > From what I read it seems you are right. My proposal would then be to:
> > 1/ Remove SIG-B as we do not support MU
> > 2/ Prepare an item to add VHT/HE SIG-B support to prepare MU transmissions.
> > 
> > Doing this we can speedup remaining work we currently have and postpone to
> > few weeks SIB-B support.
> In phase.

For 802.11ac it is also applicable I guess? (so no SIG-B in SU)

In that case, I propose to define two preambles for 802.11ac: WIFI_PREAMBLE_VHT_SU and WIFI_PREAMBLE_VHT_MU as we have in 802.11ax.

> 
> For 802.11ac it is also applicable I guess? (so no SIG-B in SU)
> 
> In that case, I propose to define two preambles for 802.11ac:
> WIFI_PREAMBLE_VHT_SU and WIFI_PREAMBLE_VHT_MU as we have in 802.11ax.

This looks like an appropriate solution to me.

(In reply to Rediet from comment #21)
> (In reply to sebastien.deronne from comment #19)
> > (In reply to Rediet from comment #17)
> > > (In reply to sebastien.deronne from comment #15)
> > > > Rediet, what is the purpose of the HT and VHT length fields?
> > > 
> > > An additional length field was introduced in the HT-SIG b/c the L-SIG_length
> > > field was used to set the duration of the packet (with L-SIG_rate @6Mbps).
> > > This HT-SIG_length gives the true length of the A-MPDU.
> > > 
> > > The logic changed a bit in the following standards, since such use was
> > > relatively redundant for SU.
> > > The length field in VHT is found in VHT-SIG-B and only concerns MU
> > > transmissions. This way the receiving station can easily obtain the real
> > > duration of its A-MPDU, when padding (using delimiters) is used to align all
> > > PSDUs.
> > > 
> > 
> > But then the L-SIG would need much more than 12 bits to express duration of
> > a A-MPDU, and I see in the 11n standard the size cannot exceed 4095 octets.
> > So I am wondering what is sent in L-SIG for A-MPDU in 11n? Or this is the
> > reason they introduced HT_LENGTH, so actually LENGTH is a messy value.
> I have to admit that it's an odd logic but 11n/ac/ax reuse L-SIG_LENGTH only
> for defining the PSDU's duration. The advantage is that legacy stations (11a
> for 11n/ac/ax, but also 11n for 11ac/ax and so on) will all be able to
> deduce PPDU duration.
> Considering that L-SIG_RATE field is set to 6 Mbps, L-SIG_LENGTH can signal
> a max duration of 5.460 ms, irrespective of the actual max A-MPDU size. 
> 
> > > > 
> > > > Also, with your definition it seems that the L-SIG_length field is expressed
> > > > in time units instead of bytes. Is this correct?
> > > 
> > > The 4 in the provided equation is actually 4 us. Forgot to mention that
> > > (important) detail.
> > > L-SIG_length = ceil ((TXTIME - T_L-Preamble) / 4 us) * 3 - 3 - m, with m = 1
> > > (for SU) and 2 (for MU and Extended-SU)
> > 
> > OK, but in 11ax the symbol duration is extended compared to 11n/ac.
> Since the duration is determined using the L-SIG_LENGTH and L-SIG_RATE, we
> should assume 11a OFDM symbol duration for this part.
> The actual number of HE data symbols is determined using the 11ax symbol
> duration (see comment 11).

Rediet, this is still unclear to me.
If you use 6 MBit/s to compute length field, you will not have enough of 12 bits for large A-MPDUs.

Also, according to the standard, m=2 for SU and not 1 as you mentioned.

For 11ax, microseconds precision in ns-3 is not enough, so I get wrong calculation when using your equation. This works for 11n/ac, but using their MCS and not 6 Mbit/s.

(In reply to sebastien.deronne from comment #24)
> Rediet, this is still unclear to me.
> If you use 6 MBit/s to compute length field, you will not have enough of 12
> bits for large A-MPDUs.
L-LENGTH and L-RATE are just used to signal the post-legacy preamble duration (TXTIME - 20us). This duration is then used to determine the actual length (by first removing the VHT/HE preambles/headers and using the 'real' MCS).
L-LENGTH is thus just a kind of alias for a given duration, since L-RATE is fixed to 6 Mbps.
> 
> Also, according to the standard, m=2 for SU and not 1 as you mentioned.
Correct.
> 
> For 11ax, microseconds precision in ns-3 is not enough, so I get wrong
> calculation when using your equation. This works for 11n/ac, but using their
> MCS and not 6 Mbit/s.
This is quite surprising. Maybe I missed a ceiling operand somewhere. Because the duration signaled through the L-SIG should be a 4us multiple. The 'real' MCS will be used in all cases to determine the TXTIME. The latter might indeed require sub-microsecond precision, whereas microsecond precision is enough for the one signaled through the L-LENGTH.

(In reply to Rediet from comment #25)
> (In reply to sebastien.deronne from comment #24)
> > Rediet, this is still unclear to me.
> > If you use 6 MBit/s to compute length field, you will not have enough of 12
> > bits for large A-MPDUs.
> L-LENGTH and L-RATE are just used to signal the post-legacy preamble
> duration (TXTIME - 20us). This duration is then used to determine the actual
> length (by first removing the VHT/HE preambles/headers and using the 'real'
> MCS).
> L-LENGTH is thus just a kind of alias for a given duration, since L-RATE is
> fixed to 6 Mbps.

Just to expose my problem, in ns-3 we compute the duration based on the real MCS.
I want to use this to fill in the LENGTH field.

So, should I instead compute the duration using 6 MBit/s?
In this case, we wont have enough of 12 bits.

> > 
> > Also, according to the standard, m=2 for SU and not 1 as you mentioned.
> Correct.
> > 
> > For 11ax, microseconds precision in ns-3 is not enough, so I get wrong
> > calculation when using your equation. This works for 11n/ac, but using their
> > MCS and not 6 Mbit/s.
> This is quite surprising. Maybe I missed a ceiling operand somewhere.
> Because the duration signaled through the L-SIG should be a 4us multiple.
> The 'real' MCS will be used in all cases to determine the TXTIME. The latter
> might indeed require sub-microsecond precision, whereas microsecond
> precision is enough for the one signaled through the L-LENGTH.

If I understand well, PHY first receives L-SIG, and can determine how long PHY should stay in RX state based on this duration. My problem is that at TX I use the real MCS, and there I have to use 6 Mbit/s (since we do not know at that stage the real MCS).

Also, since L-SIG provides already this duration, I still do not catch why we would need post L-SIG to know the duration again, or is it to refine to sub-microseconds precision?

(In reply to sebastien.deronne from comment #26)
> Just to expose my problem, in ns-3 we compute the duration based on the real
> MCS.
> I want to use this to fill in the LENGTH field.
> 
> So, should I instead compute the duration using 6 MBit/s?
> In this case, we wont have enough of 12 bits.
> 
> If I understand well, PHY first receives L-SIG, and can determine how long
> PHY should stay in RX state based on this duration. My problem is that at TX
> I use the real MCS, and there I have to use 6 Mbit/s (since we do not know
> at that stage the real MCS).
> 
> Also, since L-SIG provides already this duration, I still do not catch why
> we would need post L-SIG to know the duration again, or is it to refine to
> sub-microseconds precision?

Maybe I'm missing something important here, but why not use the following logic:
1) At TX
  a) Compute real duration using real MCS, PSDU length, and misc info (number of LTF, guard interval, disambiguation bit, etc)
  b) Use this duration to determine L-SIG LENGTH. Considering that RATE is set to 6 Mbps in L-SIG, it could require rounding (ceil)
  c) Pad if needed (due to previous rounding)
  d) Send L-SIG and VHT/HE SIG
2) At RX
  a) Extract the L-SIG LENGTH and RATE to determine the duration
  b) Extract MCS and misc info from VHT/HE SIG
  c) Determine real duration and thus PSDU length
Could this logic do the trick?

Coming back to the limitation of the L-SIG LENGTH, since its sole purpose here is to code the duration, 2^12-1 can cover up to 1366 4us-symbols, i.e. 5.464 ms. It should be enough to handle most cases. By the way, aPPDUMaxTime (5484 us, enforced in MacLow::StopMpduAggregation) seems to be related to this value (max PSDU duration + 20 us of preamble).

(In reply to Rediet from comment #27)
> (In reply to sebastien.deronne from comment #26)
> > Just to expose my problem, in ns-3 we compute the duration based on the real
> > MCS.
> > I want to use this to fill in the LENGTH field.
> > 
> > So, should I instead compute the duration using 6 MBit/s?
> > In this case, we wont have enough of 12 bits.
> > 
> > If I understand well, PHY first receives L-SIG, and can determine how long
> > PHY should stay in RX state based on this duration. My problem is that at TX
> > I use the real MCS, and there I have to use 6 Mbit/s (since we do not know
> > at that stage the real MCS).
> > 
> > Also, since L-SIG provides already this duration, I still do not catch why
> > we would need post L-SIG to know the duration again, or is it to refine to
> > sub-microseconds precision?
> 
> Maybe I'm missing something important here, but why not use the following
> logic:
> 1) At TX
>   a) Compute real duration using real MCS, PSDU length, and misc info
> (number of LTF, guard interval, disambiguation bit, etc)

This is what I do.
What is the disambiguation bit? We do not have this supported for the moment I guess.

>   b) Use this duration to determine L-SIG LENGTH. Considering that RATE is
> set to 6 Mbps in L-SIG, it could require rounding (ceil)

If we used duration at a), why do we need RATE again here?

>   c) Pad if needed (due to previous rounding)

Not clear what you mean here

>   d) Send L-SIG and VHT/HE SIG
> 2) At RX
>   a) Extract the L-SIG LENGTH and RATE to determine the duration

>   b) Extract MCS and misc info from VHT/HE SIG
>   c) Determine real duration and thus PSDU length
> Could this logic do the trick?
> 
> Coming back to the limitation of the L-SIG LENGTH, since its sole purpose
> here is to code the duration, 2^12-1 can cover up to 1366 4us-symbols, i.e.
> 5.464 ms. It should be enough to handle most cases. By the way, aPPDUMaxTime
> (5484 us, enforced in MacLow::StopMpduAggregation) seems to be related to
> this value (max PSDU duration + 20 us of preamble).

It's not clear for me what the difference between the duration in a) and the "real" duration? is it just the precision (sub-microseconds)?

Leonardo sent me a Matlab code that made this clearer.

I have just not understood what you mean by disambiguation bit and padding.

(In reply to sebastien.deronne from comment #29)
> Leonardo sent me a Matlab code that made this clearer.
Great!
> 
> I have just not understood what you mean by disambiguation bit and padding.
Sorry, I ended up mixing everything. After some thought, I don't think that we need the disambiguation bit since it's related to the Packet Extension principle (adding extra dummy data after the FEC so as to let the receiver enough time to process its data). In my opinion, we can reasonably assume that all receivers have the capacity of replying directly within SIFS (without this extra time), so we can ignore this disambiguation bit and hard code it to 0 (3rd bit of Packet Extension field in HE-SIG-A).

As for the padding, the one that we'll eventually have to be careful with is the pre-FEC padding. There are some subtleties as to where receiver decoding should stop. This is signaled through the "a"-factor bit (first 2 bits of Packet Extension field). You can have a look at 11-15-0810r1 (https://mentor.ieee.org/802.11/dcn/15/11-15-0810-01-00ax-he-phy-padding-and-packet-extension.pptx) that resulted in PHY motion 59. The underlying logic is detailed there. I frankly don't know if it'll be an issue during implementation, but it might. You will surely have more insight on this point.

This is already included in the current code