|
Bugzilla – Full Text Bug Listing |
| Summary: | When the TXOP limit is nonzero, packets should be fragmented so that the TXOP limit is not exceeded | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | sebastien.deronne |
| Component: | wifi | Assignee: | sebastien.deronne |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3.26 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Proposed fix | ||
Does anyone agree/disagree with the proposed fix? Can we deliver this for the next release? changeset 12675:214c62e9a663 |
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 :-)