Bug 2615 - When the TXOP limit is nonzero, packets should be fragmented so that the TXOP limit is not exceeded
When the TXOP limit is nonzero, packets should be fragmented so that the TXOP...
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: wifi
ns-3.26
All All
: P3 normal
Assigned To: sebastien.deronne
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-01-08 11:42 UTC by sebastien.deronne
Modified: 2017-02-06 14:40 UTC (History)
1 user (show)

See Also:


Attachments
Proposed fix (20.57 KB, patch)
2017-01-08 11:42 UTC, sebastien.deronne
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description sebastien.deronne 2017-01-08 11:42:49 UTC
Created attachment 2741 [details]
Proposed fix

This was reported offline by Ioannis few months ago. If the duration of the packet exceeds the TXOP limit, the frame should be fragmented.

IEEE 802.11-2012 (9.19.2.2 EDCA TXOPs) says:
"When the TXOP limit is nonzero, a STA shall fragment an individually addressed MSDU so that the transmission of the first MPDU of the TXOP does not cause the TXOP limit to be exceeded at the PHY rate selected for the initial transmission attempt of that MPDU. The TXOP limit may be exceeded, when using a lower PHY rate than selected for the initial transmission attempt of the first MPDU, for a retransmission of an MPDU, for the initial transmission of an MPDU if any previous MPDU in the current MSDU has been retransmitted, or for group addressed MSDUs. When the TXOP limit is exceeded due to the retransmission of an MPDU at a reduced PHY rate, the STA shall not transmit more than one MPDU in the TXOP."

It was not something really obvious to implement, and it required some bugs to be fixed upon. I finally managed to have it working (see attachment) but I do not pretend this is the most optimal way. Feel free to provide comments/remarks/suggestions to improve the patch :-)
Comment 1 sebastien.deronne 2017-01-24 14:01:53 UTC
Does anyone agree/disagree with the proposed fix?
Comment 2 sebastien.deronne 2017-02-04 02:35:02 UTC
Can we deliver this for the next release?
Comment 3 sebastien.deronne 2017-02-06 14:40:13 UTC
changeset 12675:214c62e9a663