View
213
Download
1
Category
Preview:
Citation preview
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 1
doc.:IEEE 802.11-01/566r1
Submission
Multiple Frame Exchanges during Multiple Frame Exchanges during EDCF TXOPEDCF TXOP
Sunghyun Choi1, Javier del Prado1, Atul Garg1, Maarten Hoeben3, Stefan Mangold2,
Sai Shankar1, and Menzo Wentink3
Philips1, Aachen University2, and Intersil3
sunghyun.choi@philips.com and mwentink@intersil.com
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 2
doc.:IEEE 802.11-01/566r1
Submission
Problem StatementProblem Statement
• Per 802.11e/D1.3, it is clear that one cannot have multiple frame (i.e., MSDU) exchanges during a non-polled TXOP (or EDCF TXOP).– 802.11e/D1.2 was not very clear in that; see
01/534 for related discussion.
• However, allowing the multiple frame exchanges (or EDCF TXOP Bursting) looks very attractive.– See the next for the details.
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 3
doc.:IEEE 802.11-01/566r1
Submission
Advantages of EDCF TXOP BurstingAdvantages of EDCF TXOP Bursting• Will reduce network overhead
– Without bursting available, an ESTA must backoff after each MSDU transmission
• Will increase bandwidth fairness among the same priority queues, virtually independent from the frame sizes.– Without bursting available, the ESTA with
larger MSDUs will use the channel more
• Should not affect the rest of HCF as the EDCF TXOP is limited by “CP TXOP Limit” in QoS Parameter Set element anyway.
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 4
doc.:IEEE 802.11-01/566r1
Submission
Proposed EDCF TXOP BurstingProposed EDCF TXOP Bursting
• During an EDCF TXOP, ESTA may transmit multiple frames (i.e., MSDUs) from the same queue (i.e., from the same Access Category per 01/565r0).
• Once there is a transmission failure, the EDCF TXOP ends, and the ESTA goes into backoff.
• Without a transmission failure, the ESTA goes to backoff after the final frame exchange.
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 5
doc.:IEEE 802.11-01/566r1
Submission
Duration and NAV RulesDuration and NAV Rules
• EDCF bursting uses Duration rules similar to fragment bursting– Each MPDU protects up to the next frame
exchange via Duration.
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 6
doc.:IEEE 802.11-01/566r1
Submission
EDCF TXOP Limit per ACEDCF TXOP Limit per AC
• Replace the “CP TXOP Limit” in QoS Parameter Set element with four “CP TXOP Limit [AC]’s” – One per Access Category (AC) (ref. 01/565r0)
• Desirable along with the EDCF TXOP bursting– Will enable bursting size tuning per AC
depending on the traffic types – Can achieve weighted bandwidth sharing
among ACs
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 7
doc.:IEEE 802.11-01/566r1
Submission
Normative Text Changes from D1.3Normative Text Changes from D1.3• Revise 9.10.2.2 as follows:
– Title should read “Duration values within TXOPs”– “TXOP” should be replaced by “polled TXOP”– Add the following paragraph at the end of 9.10.2.2: “Each
frame during a TXOP obtained by winning EDCF contention contains duration information that defines the duration until the end of the next frame exchange sequence. Duration information from each frame shall be used to update the NAV to indicate busy until the end of the next frame exchange sequence.”
• Replace the first sentence of 9.10.3 with:– “A TXOP obtained by winning EDCF contention may be used to
send one or more frame exchange sequences of the frames of the same AC with total medium occupancy time not exceeding CP TXOP limit [AC] from the QoS parameter set element in the beacon.”
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 8
doc.:IEEE 802.11-01/566r1
Submission
Normative Text Changes from D1.3Normative Text Changes from D1.3• In Clause 7.3.2.14:
– Replace the third paragraph with: “The CP TXOP limits [AC] field contains 8 octects which specify 4 time limits on TXOPs that are not granted by QoS (+)CF-Polls, for access categories 0 through 3, respectively. Each CP TXOP limit is 2 octets in length and contains the unsigned integer number of 16-microsecond periods. All non-polled WSTA TXOPs during the CP last no longer than the period specified by the corresponding CP TXOP limit value. A CP TXOP limit [AC] value of 0 indicates that each non-polled TXOP of access category AC during the CP can be used to transmit a single MPDU at any rate in the operational rate set of the QBSS. CP TXOP Limit [AC] values update the dot11CPTXOPLimit[AC] MIB values when received by a QSTA.”
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 9
doc.:IEEE 802.11-01/566r1
Submission
Normative Text Changes from D1.3Normative Text Changes from D1.3
• In Clause 7.3.2.14 and Figure 42.6:– Replace “CP TXOP Limit” with “CP TXOP
Limits,” “CP TXOP Limit [AC],” or “CP TXOP Limit [0] … CP TXOP Limit [3]” depending on the context
• In Annex D:– Replace “dot11CPTXOPLimit” with
“dot11CPTXOPLimit[0…3]
November 2001
S. Choi, Philips & M.M. Wentink, IntersilSlide 10
doc.:IEEE 802.11-01/566r1
Submission
MotionMotion
• Move to empower the TGe editor to revise the non-polled TXOP usage by incorporating normative text changes on slides 7 - 9 of document 01/566r1, and by changing wording on non-polled TXOP usage elsewhere in the TGe draft as may be necessary to make the revised TGe draft consistent with the above changes.
Recommended