802.11e TXOP

802.11e TXOP

[Tom Henderson, 2016-04-20 17:15:12]

Initial question:  we have existing 802.11e per-AC attributes in RegularWifiMac,
but this one is in Dcf?  How does one configure this on a per-AC basis, or is
that not supported?

[S. Deronne, 2016-04-20 19:53:18]

On 2016/04/20 17:15:12, Tom Henderson wrote:
> Initial question:  we have existing 802.11e per-AC attributes in
RegularWifiMac,
> but this one is in Dcf?  How does one configure this on a per-AC basis, or is
> that not supported?

It is configurable like CWmin and CWmax. In case of DCF, TXOP is set to 0 ms.
TXOP will be differently configured for each AC, please refer to changes done in
wifi-mac.cc.

[Stefano Avallone, 2016-04-23 21:18:10]

The changes look okay to me, though my knowledge of the wifi code is still
rather limited and I may very likely miss something. The only thing I found a
little bit weird is to define the values of the TXOP for all the classes within
the code. Indeed, those values are the default ones but alternative values can
be used as well (in practice, APs can advertise different values in the EDCA
Parameter Set element they send in, e.g., beacon frames). I am not sure,
however, if it is worth to support configurable TXOP values.

[S. Deronne, 2016-04-24 12:52:08]

On 2016/04/23 21:18:10, Stefano Avallone wrote:
> The changes look okay to me, though my knowledge of the wifi code is still
> rather limited and I may very likely miss something. The only thing I found a
> little bit weird is to define the values of the TXOP for all the classes
within
> the code. Indeed, those values are the default ones but alternative values can
> be used as well (in practice, APs can advertise different values in the EDCA
> Parameter Set element they send in, e.g., beacon frames). I am not sure,
> however, if it is worth to support configurable TXOP values.

You are correct, but the EDCA Parameter Set is currently not implemented so I
mimic here what we have so far for CWmin and CWmax.
We could extend a bit the scope of this and define the EDCA Parameter Set and
allow configuration of CWmin, CWmax and TXOP values, but I am also not sure
whether this is really used in the field.

[S. Deronne, 2016-05-01 20:47:57]

Added a new patch set addressing the suggestion from Stefano.

[Tom Henderson, 2016-06-24 23:16:02]

One final question I have is whether you see an opportunity to create a new
trace source somewhere that can be used to trace the TXOP time that was actually
used?  It could be used for testing, and I have seen the need on LAA Wifi
coexistence to be able to log the actual channel occupancy durations used by a
STA (which presently I have to do by post-processing the phy trace and
concatenating signals). 

For instance, keep a state variable for the start of a TXOP time (such as
m_startTxopTime), and then create a ns3::Time::TracedValue that is updated to
the quantity (Simulator::Now() - m_startTxopTime) when the TXOP actually ends.

The question I have is where is a good location in the MAC code somewhere to
compute when the TXOP actually ends?

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
File examples/wireless/80211e-txop.cc (right):

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:26: #include "ns3/ipv4-global-routing-helper.h"
this header is not needed if the internet-module is included.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:30: // It defines 4 independant Wi-Fi networks
(working on different channels).
independent

I would also clarify "working on different logical channels on the same
"ns3::YansWifiPhy" channel object".

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:32: // continously transmits data packets to
its respective AP.
continuously

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:42: // - STA A sends AC_BE traffic to AP A with
default EDCA parameters;
clarify:  s/default EDCA parameters/default BE TXOP value of 0 (1 MSDU)/

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:43: // - STA B sends AC_BE traffic to AP B with
non-default EDCA parameters;
clarify:  s/non-default EDCA parameters/non-default BE TXOP of 3.008 ms/

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:45: // - STA D sends AC_VI traffic to AP D with
non-default EDCA parameters;
clarify: s/default EDCA parameters/default AC_VI TXOP of 3.008 ms

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:48: // an can choose the payload size and the
simulation duration.
and

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:83: WifiHelper wifi;
add comment that the default standard of 802.11a will be selected by this helper
since the program doesn't specify another one

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:96: "ActiveProbing", BooleanValue (false));
I see this ActiveProbing attribute set often in examples, but the default is
already false -- suggest to remove.  Same with BeaconInterval set to 102400. 
The key one to show here is QosSupported=true.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:131: edca->SetTxopLimit (MilliSeconds (3008));
Should be MicroSeconds

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:274: myClientC.SetAttribute ("AccessClass",
UintegerValue (4)); //AC_VI
VI is value 2, not 4 (which is BE_NQOS)

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:291: myClientD.SetAttribute ("AccessClass",
UintegerValue (4)); //AC_VI
same comment as above

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
File src/applications/model/onoff-application.cc (right):

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
src/applications/model/onoff-application.cc:91: "The access class: AC_BE, AC_VO,
AC_VI, AC_BK",
Suggest to document:
"The access class:  AC_BE (0), AC_BK (1), AC_VI (2), AC_VO (3)

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
src/applications/model/onoff-application.cc:94: MakeUintegerChecker<uint8_t> ())
MakeUintegerChecker<uint8_t> (0,3))

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
File src/applications/model/onoff-application.h (right):

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
src/applications/model/onoff-application.h:166: uint8_t         m_ac;          
//!< Acces class for QoS-tag
Access

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/dcf.h
File src/wifi/model/dcf.h (right):

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/dcf.h#newc...
src/wifi/model/dcf.h:60: * \param txopLimit the TXOP limit
add comment here also that zero time corresponds to default DCF

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/edca-param...
File src/wifi/model/edca-parameter-set.h (right):

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/edca-param...
src/wifi/model/edca-parameter-set.h:43: void SetQosInfo (uint8_t qosInfo);
doxygen needed on all methods

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/sta-wifi-m...
File src/wifi/model/sta-wifi-mac.cc (right):

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/sta-wifi-m...
src/wifi/model/sta-wifi-mac.cc:757: edca->SetTxopLimit (txopLimit);
seems like this block of code is duplicated; can it be factored into a method?

Why the scaling factor of 32; can you reference the standard here?

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

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/wifi-mac.c...
src/wifi/model/wifi-mac.cc:422: dcf->SetTxopLimit (MilliSeconds (3264));
all of these should be MicroSeconds not MilliSeconds

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/wifi-mac.c...
src/wifi/model/wifi-mac.cc:446: dcf->SetTxopLimit (MilliSeconds (0));
better to set MicroSeconds (0) to avoid copy/paste errors

[S. Deronne, 2016-06-28 21:12:01]

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
File examples/wireless/80211e-txop.cc (right):

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:26: #include "ns3/ipv4-global-routing-helper.h"
On 2016/06/24 23:16:01, Tom Henderson wrote:
> this header is not needed if the internet-module is included.

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:30: // It defines 4 independant Wi-Fi networks
(working on different channels).
On 2016/06/24 23:16:01, Tom Henderson wrote:
> independent
> 
> I would also clarify "working on different logical channels on the same
> "ns3::YansWifiPhy" channel object".

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:32: // continously transmits data packets to
its respective AP.
On 2016/06/24 23:16:01, Tom Henderson wrote:
> continuously

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:42: // - STA A sends AC_BE traffic to AP A with
default EDCA parameters;
On 2016/06/24 23:16:01, Tom Henderson wrote:
> clarify:  s/default EDCA parameters/default BE TXOP value of 0 (1 MSDU)/

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:43: // - STA B sends AC_BE traffic to AP B with
non-default EDCA parameters;
On 2016/06/24 23:16:01, Tom Henderson wrote:
> clarify:  s/non-default EDCA parameters/non-default BE TXOP of 3.008 ms/

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:45: // - STA D sends AC_VI traffic to AP D with
non-default EDCA parameters;
On 2016/06/24 23:16:01, Tom Henderson wrote:
> clarify: s/default EDCA parameters/default AC_VI TXOP of 3.008 ms

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:48: // an can choose the payload size and the
simulation duration.
On 2016/06/24 23:16:01, Tom Henderson wrote:
> and

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:48: // an can choose the payload size and the
simulation duration.
On 2016/06/24 23:16:01, Tom Henderson wrote:
> and

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:83: WifiHelper wifi;
On 2016/06/24 23:16:01, Tom Henderson wrote:
> add comment that the default standard of 802.11a will be selected by this
helper
> since the program doesn't specify another one

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:96: "ActiveProbing", BooleanValue (false));
On 2016/06/24 23:16:01, Tom Henderson wrote:
> I see this ActiveProbing attribute set often in examples, but the default is
> already false -- suggest to remove.  Same with BeaconInterval set to 102400. 
> The key one to show here is QosSupported=true.

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:131: edca->SetTxopLimit (MilliSeconds (3008));
On 2016/06/24 23:16:01, Tom Henderson wrote:
> Should be MicroSeconds

Done.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:274: myClientC.SetAttribute ("AccessClass",
UintegerValue (4)); //AC_VI
On 2016/06/24 23:16:01, Tom Henderson wrote:
> VI is value 2, not 4 (which is BE_NQOS)

I remember I tried with 2 and it did not work, and we define this in our code:

TID	Access class
7	AC_VO
6	AC_VO
5	AC_VI
4	AC_VI
3	AC_BE
0	AC_BE
2	AC_BK
1	AC_BK

What is the correct value?

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
File src/applications/model/onoff-application.cc (right):

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
src/applications/model/onoff-application.cc:91: "The access class: AC_BE, AC_VO,
AC_VI, AC_BK",
On 2016/06/24 23:16:01, Tom Henderson wrote:
> Suggest to document:
> "The access class:  AC_BE (0), AC_BK (1), AC_VI (2), AC_VO (3)

Done.

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
src/applications/model/onoff-application.cc:94: MakeUintegerChecker<uint8_t> ())
On 2016/06/24 23:16:01, Tom Henderson wrote:
> MakeUintegerChecker<uint8_t> (0,3))

Done.

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
File src/applications/model/onoff-application.h (right):

https://codereview.appspot.com/293190043/diff/40001/src/applications/model/on...
src/applications/model/onoff-application.h:166: uint8_t         m_ac;          
//!< Acces class for QoS-tag
On 2016/06/24 23:16:01, Tom Henderson wrote:
> Access

Done.

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/dcf.h
File src/wifi/model/dcf.h (right):

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/dcf.h#newc...
src/wifi/model/dcf.h:60: * \param txopLimit the TXOP limit
On 2016/06/24 23:16:02, Tom Henderson wrote:
> add comment here also that zero time corresponds to default DCF

Done.

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/edca-param...
File src/wifi/model/edca-parameter-set.h (right):

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/edca-param...
src/wifi/model/edca-parameter-set.h:43: void SetQosInfo (uint8_t qosInfo);
On 2016/06/24 23:16:02, Tom Henderson wrote:
> doxygen needed on all methods

Done.

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/sta-wifi-m...
File src/wifi/model/sta-wifi-mac.cc (right):

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/sta-wifi-m...
src/wifi/model/sta-wifi-mac.cc:757: edca->SetTxopLimit (txopLimit);
On 2016/06/24 23:16:02, Tom Henderson wrote:
> seems like this block of code is duplicated; can it be factored into a method?
> 
> Why the scaling factor of 32; can you reference the standard here?

Done.

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

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/wifi-mac.c...
src/wifi/model/wifi-mac.cc:422: dcf->SetTxopLimit (MilliSeconds (3264));
correct, thanks.

https://codereview.appspot.com/293190043/diff/40001/src/wifi/model/wifi-mac.c...
src/wifi/model/wifi-mac.cc:446: dcf->SetTxopLimit (MilliSeconds (0));
On 2016/06/24 23:16:02, Tom Henderson wrote:
> better to set MicroSeconds (0) to avoid copy/paste errors

Done.

[S. Deronne, 2016-06-29 19:26:17]

I guess something could be done in EdcaTxopN, but I do not really see the need
for an additional trace source.
But maybe I miss what you want to get.

[Tom Henderson, 2016-06-29 19:41:04]

On 2016/06/29 19:26:17, S. Deronne wrote:
> I guess something could be done in EdcaTxopN, but I do not really see the need
> for an additional trace source.
> But maybe I miss what you want to get.

There is no straightforward way to get statistics on the actual TXOP durations
used.

  typedef void (* TxopDurationCallback)
    (Time start, Time duration, enum AcIndex acIndex);

[Tom Henderson, 2016-06-29 19:58:34]

>
https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
> examples/wireless/80211e-txop.cc:274: myClientC.SetAttribute ("AccessClass",
> UintegerValue (4)); //AC_VI
> On 2016/06/24 23:16:01, Tom Henderson wrote:
> > VI is value 2, not 4 (which is BE_NQOS)
> 
> I remember I tried with 2 and it did not work, and we define this in our code:
> 
> TID	Access class
> 7	AC_VO
> 6	AC_VO
> 5	AC_VI
> 4	AC_VI
> 3	AC_BE
> 0	AC_BE
> 2	AC_BK
> 1	AC_BK
> 
> What is the correct value?

OK, I see the problem-- at the application level, we should use 802.1d/802.1q
User Priority values or ToS.  

We could instead set ToS/DSCP and map from ToS/DSCP to 802.1d and then to 802.11
access class.  This was the point of my original patch here: 
https://codereview.appspot.com/277230044/patch/1/10002

I tend to favor a general solution involving ToS because if we patch OnOff in
this way to directly add QosTag, users will next ask for this patch for other
applications, and then the interaction between this tag and the ToS will need to
be defined.

Note also that Stefano has a proposal for Tos support in address objects here:

https://codereview.appspot.com/294280043/

I suggest we agree on a general solution so we can move this and bug 2241
forward.

[Stefano Avallone, 2016-06-29 21:41:04]

On 2016/06/29 19:58:34, Tom Henderson wrote:
> > > VI is value 2, not 4 (which is BE_NQOS)
> > 
> > I remember I tried with 2 and it did not work, and we define this in our
code:
> > 
> > TID	Access class
> > 7	AC_VO
> > 6	AC_VO
> > 5	AC_VI
> > 4	AC_VI
> > 3	AC_BE
> > 0	AC_BE
> > 2	AC_BK
> > 1	AC_BK
> > 
> > What is the correct value?
> 
> OK, I see the problem-- at the application level, we should use 802.1d/802.1q
> User Priority values or ToS.  

Correct. User priorities (in the range 0..7) are derived from the ToS byte
(IPv4) or the Traffic Class byte (IPv6) and then mapped to access categories as
shown above.
 
> We could instead set ToS/DSCP and map from ToS/DSCP to 802.1d and then to
802.11
> access class.  This was the point of my original patch here: 
> https://codereview.appspot.com/277230044/patch/1/10002
> 
> I tend to favor a general solution involving ToS because if we patch OnOff in
> this way to directly add QosTag, users will next ask for this patch for other
> applications, and then the interaction between this tag and the ToS will need
to
> be defined.
> 
> Note also that Stefano has a proposal for Tos support in address objects here:
> 
> https://codereview.appspot.com/294280043/
> 
> I suggest we agree on a general solution so we can move this and bug 2241
> forward.

In the last couple of days I managed to work on the codereview mentioned by Tom
and I am very close to publish a new version. Basically, I added the priority
attribute to the sockets and a priority tag to the packets which carries the
priority of the socket they belong to. IPv4 derives the priority from bits 3-6
of the ToS. If the packet is sent to a wifi interface, the "select_queue"
function of the 802.11 mac reassigns the priority of a packet based on the most
significant three bits of the ToS (or Traffic Class in case of IPv6). The
priority of the packet thus becomes the user priority of the packet, which is
used to determine the access category. Hence, I thought we could use the
priority tag in place of the QoS tag. The priority tag is just the equivalent of
the Linux skb->priority field and is hence more general. In fact, I plan to
modify pfifo_fast so that it will use the priority to classify the packets (as
Linux does), thus eliminating the dependency on filters residing in the internet
module...

Well, the code should explain these things better... Tomorrow I should be able
to prepare a simple test for the wifi case and hopefully I will publish the
code.

Bests,
Stefano

[Stefano Avallone, 2016-06-29 21:42:35]

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
File examples/wireless/80211e-txop.cc (right):

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:29: // This is an example that illustrates
802.11 QoS for different Access Classes.
I think Access Categories is used by the 802.11 standard.

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:36: //  Network A (36)   Network B (40)  
Network C (44)   Network D (48)
Replace "Network" with BSS? I think BSS is more precise here.

[Stefano Avallone, 2016-06-30 17:49:26]

> Well, the code should explain these things better... Tomorrow I should be able
> to prepare a simple test for the wifi case and hopefully I will publish the
> code.

Preparing a test was a bit tricky... Anyway, here it is the complete code
review:


https://codereview.appspot.com/302880043/

[S. Deronne, 2016-07-01 18:27:07]

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
File examples/wireless/80211e-txop.cc (right):

https://codereview.appspot.com/293190043/diff/40001/examples/wireless/80211e-...
examples/wireless/80211e-txop.cc:29: // This is an example that illustrates
802.11 QoS for different Access Classes.
On 2016/06/29 21:42:35, Stefano Avallone wrote:
> I think Access Categories is used by the 802.11 standard.

Done.

[S. Deronne, 2016-07-01 18:28:41]

Stefano, when would you be able to provide a wifi test case?

[Stefano Avallone, 2016-07-01 20:00:47]

On 2016/07/01 18:28:41, S. Deronne wrote:
> Stefano, when would you be able to provide a wifi test case?

In the code review I just published:

https://codereview.appspot.com/302880043/

there is the ns-3-wifi-ac-mapping. Isn't it a suitable test case for wifi?
Suggestions are welcome, of course.

[S. Deronne, 2016-07-02 08:57:25]

Stefano, where do those values come from?

  AddTestCase (new WifiAcMappingTest (0xb8, 2), TestCase::QUICK); // EF in AC_VI
  AddTestCase (new WifiAcMappingTest (0x28, 1), TestCase::QUICK); // AF11 in
AC_BK
  AddTestCase (new WifiAcMappingTest (0x70, 0), TestCase::QUICK); // AF32 in
AC_BE
  AddTestCase (new WifiAcMappingTest (0xc0, 3), TestCase::QUICK); // CS7 in
AC_VO

I tried them but still I get always AC_BE traffic.

[S. Deronne, 2016-07-02 09:09:14]

On 2016/07/02 08:57:25, S. Deronne wrote:
> Stefano, where do those values come from?
> 
>   AddTestCase (new WifiAcMappingTest (0xb8, 2), TestCase::QUICK); // EF in
AC_VI
>   AddTestCase (new WifiAcMappingTest (0x28, 1), TestCase::QUICK); // AF11 in
> AC_BK
>   AddTestCase (new WifiAcMappingTest (0x70, 0), TestCase::QUICK); // AF32 in
> AC_BE
>   AddTestCase (new WifiAcMappingTest (0xc0, 3), TestCase::QUICK); // CS7 in
> AC_VO
> 
> I tried them but still I get always AC_BE traffic.

Ok, my fault, it's working fine now.
I will post a last patch set that should be applied on top of Stefano's code.

Tom, wrt to the trace source, I would like to deliver the code to ns-3-dev and
eventually add the trace source later, because the code should be tested a bit
before the release so it should not be delivered too late. Let me know what you
think, otherwise I'll try to make a patch set including the trace source, but it
will be postponed of one week then.

[Stefano Avallone, 2016-07-02 10:49:02]

On 2016/07/02 09:09:14, S. Deronne wrote:
> On 2016/07/02 08:57:25, S. Deronne wrote:
> > Stefano, where do those values come from?
> > 
> >   AddTestCase (new WifiAcMappingTest (0xb8, 2), TestCase::QUICK); // EF in
> AC_VI
> >   AddTestCase (new WifiAcMappingTest (0x28, 1), TestCase::QUICK); // AF11 in
> > AC_BK
> >   AddTestCase (new WifiAcMappingTest (0x70, 0), TestCase::QUICK); // AF32 in
> > AC_BE
> >   AddTestCase (new WifiAcMappingTest (0xc0, 3), TestCase::QUICK); // CS7 in
> > AC_VO
> > 
> > I tried them but still I get always AC_BE traffic.
> 
> Ok, my fault, it's working fine now.

I think you figured it out by yourself, anyway... The three most significant
bits of the ToS byte determine the user priority, which is then mapped to the AC
as you reported in a previous post. E.g., in case of EF the ToS is set to 0xb8,
i.e., 10111000 -> the user priority is 101, i.e., 5 which is mapped to AC_VI.

[Tom Henderson, 2016-07-02 15:37:02]

On 2016/07/02 09:09:14, S. Deronne wrote:
> On 2016/07/02 08:57:25, S. Deronne wrote:
> > Stefano, where do those values come from?
> > 
> >   AddTestCase (new WifiAcMappingTest (0xb8, 2), TestCase::QUICK); // EF in
> AC_VI
> >   AddTestCase (new WifiAcMappingTest (0x28, 1), TestCase::QUICK); // AF11 in
> > AC_BK
> >   AddTestCase (new WifiAcMappingTest (0x70, 0), TestCase::QUICK); // AF32 in
> > AC_BE
> >   AddTestCase (new WifiAcMappingTest (0xc0, 3), TestCase::QUICK); // CS7 in
> > AC_VO
> > 
> > I tried them but still I get always AC_BE traffic.
> 
> Ok, my fault, it's working fine now.
> I will post a last patch set that should be applied on top of Stefano's code.
> 
> Tom, wrt to the trace source, I would like to deliver the code to ns-3-dev and
> eventually add the trace source later, because the code should be tested a bit
> before the release so it should not be delivered too late. Let me know what
you
> think, otherwise I'll try to make a patch set including the trace source, but
it
> will be postponed of one week then.

Yes, let's leave the trace source as a separate future feature.

[S. Deronne, 2016-07-05 21:02:13]

Final patch set available, still need to include trace source (non blocking for
delivery).

[S. Deronne, 2016-07-14 19:04:02]

Pushed!