Qos related issues in 802.11 MAC and Baseline document #360

1. Qos related issues in 802.11 MAC and Baseline document #360 Dr. Rajugopal Gubbi, Matthew Fischer and Dr. George Kondylis Broadcom, Corp.

2. What are the modifications? • Providing distributed, but controlled channel access within CFP • Resolving issues in 802.11-1999 to assist in Qos operation • Resolving issues in Tx-ops in the current Qos-baseline document

3. Providing distributed, but controlled channel access within CFP

4. What is the problem? • There were several proposals for EDCF and many papers • Issue related to operating with legacy stations makes the proposals complex and not completely workable. • None of the current EDCF proposals completely prevent collisions of frames of different priority • Backoff after collisions needs to be different (compared to legacy algorithm) for the current EDCF proposals • Hidden node and near-far effects worsens situation in all the current EDCF proposals • Using +CF-Poll in CP does not solve this problem as the latency/jitter for those frames is not bound especially in the presence of legacy stations

5. Why not just use CFP for all traffic? As defined today in 360r1, • EAP/EPC can not always predict the traffic correctly • when Multiple periodic streams are present, the CFP-rep-rate can not always be optimized for all traffic and all periodicity without wasting some bandwidth within CFP. • And some QOS flows may be bursty • or inefficient polling of ALL (E)STA • low-latency, low-duty cycle, periodic traffic might also need faster beacon rate Hence there is a need to allow distributed, but controlled channel access for Qos data flow within parts of CFP

6. What does this paper discuss? • This paper discusses the modifications to Qos baseline document. The modifications use the already accepted mechanisms, in 360r1, in an extended manner to achieve the goal of providing overall Qos with no increase in complexity to provide better efficiency.

7. What are the modifications? (1) • Use contention control within CFP with following generalization of its definition • Generalize the definition of CC so that the ESTAs can send ANY pending control/management or Qos-data frame • Use Duration/ID field of CC frame to indicate the end of controlled contention period (CCP) with b15=1 and b14=0 (as required in the current definition in Table-3). • Provide a “CC-OP-limit” within CC frame as the max limit on the duration of frame transmission within CCP • RR frames are solicited by EAP/EPC by limiting the CC-OP-limit to the duration of RR frame at the PHY rate used for CC • Provide priority RANGE (px to py) to limit the class of traffic within CCP • px=py means there is only one priority is allowed during CCP. • Control and management frames can be sent in any CCP

8. b7 b3 b6:b4 b2:b0 Lower limit on priority Upper limit on priority RSV RSV What are the modifications? (2) • New format for CC Frame Max limit (in micro seconds) on the duration of data/control/management frame during the current CCP Covers the entire CCP that follows the current CC frame b15=1 and b14=0 as in Table-3 Note: The Reserved octet can be used for CC-OP-limit field with values in multiples of 16 Hence save two octets in the CC frame

9. What are the modifications? (3) • Little change to the channel access method during CCP (almost same as currently defined in clause 9.2) • All ESTAs use DIFS for channel access during CCP • All ESTAs use the currently defined (clause 9.2.4) backoff algorithm during CCP. • Change of transmission attempt from one priority frame to another is treated same as different MSDU attempt during CP (clause 9.2.4). Use of SLRC/SSRC and SRC/LRC. • Retry procedure is same as that in 802.11-1999 (clause 9.2.5.3). The retry limits can be defined to be different for Qos-Data frames. • CW counter for Qos-data is reset at the beginning every CCP to provide fair access. Otherwise, an ESTA that has backed off in an earlier CCP will be at disadvantage compared to the ESTA that constructed the frame in between two CCPs.

10. What are the modifications? (4) • CW is also reset when SLRC or SSRC reaches its limit, as defined in clause 9.2.4, to provide preference to ESTA that did not have transmission opportunity for a long time. • NAV set in ESTAs, is applicable only for CP. During CCP ESTAs are allowed to transmit if priority range and CC-OP-limit are met • CCP can end early if EAP/EPC grabs the channel after PIFS • All ESTAs sense the channel becoming busy after PIFS and interprets that as the early-end of CCP, even though the received frame from EAP/EPC may be corrupted • EAP/EPC always sends the CC frame with zero CCP duration when it ends the CCP early. AND uses PIFS for the following data+poll so that if the channel was free for a while the start of second frame from the EAP/EPC clearly signals the end of CCP • RTS/CTS within CCP (as was proposed to be within CFP) to find out if the destination device is within range. NAV is not set by the ESTAs of the same QBSS. RTS is limited to cover the ONLY frame following the response CTS and ack, if any.

11. CC with Zero CCP duration What are the modifications? (5) • Example of CFP operation D1+X-Poll frame D1+X-Poll frame D1+X-Poll frame Early ending CCP CC frame CC frame CC frame CF-End Normally ending CCP Beacon TBTT TBTT PIFS Controlled Contention Period(CCP) Controlled Contention Period(CCP) SIFS PIFS PIFS PIFS PIFS SIFS Contention-Free Period(CFP) Contention Period(CP) EAP/EPC uses CF-Poll, Qos-CF-Poll, CF-Multi-Poll and CF-Sch to provide Tx-ops to ESTAs CCP: ESTAs use channel access mechanism described before for CFP

12. What are the modifications? (6) • Summary of the proposed changes • All ESTAs recognize CC frame • Limit transmissions as per CC-OP-limit indicated in CC-frame • Limit transmissions to priority range indicated in CC frame • Reset CW to CWmin at the beginning of CCP for the pending control/management/Qos-data frames • Recognize the channel takeover by EAP/EPC after PIFS to signal the end of CCP • EAP/EPC sends CC frame with zero duration to end the CCP early. And uses PIFS for the next data+poll frame. • Use of RTS/CTS within CCP, similar to the proposal for its use within CFP.

13. What are the advantages of this modification? • CFP provides guaranteed transmission opportunities while CCP within CFP provides flexibility of distributed access. Best of both worlds! • Little needs to be done at ESTA for priority differentiation within CCP • No new back-off mechanism at ESTA • No issues due to legacy stations • Bandwidth wastage within CFP is eliminated • RR frames, TCSIZE indications can be used in CCP also to continue to provide information to EAP/EPC • EAP/EPC can choose CCP for ONE priority and hence completely avoid the collision among frames of different priorities • ESTAs can use CP (also) for control/management/non-Qos data transfers. • Any proposed EDCF mechanism works better in CCP (than in CP)

14. Resolving issues in 802.11-1999 to assist in Qos operation

15. What are the issues? • There are five issues in 802.11-1999 that needs to be fixed for proper Qos operation. The issues are, • Not limiting transmission of all STAs during CP to end before the start of CFP for all PHYs - Should be fixed in clause 9, Qos baseline document (#360). • Not limiting transmission of a polled STA to a duration as decided by PC - Should be fixed in clause 9, Qos baseline document (#360). • Not specifying Flow spec - Fixed in doc#360, clause 7. But needs modifications • Limiting the maximum CFP duration to accommodate at least MaxMPDUTime in CP - modification suggested later in the presentation. • The polling list clause is outdated and is an hindrance to the Qos operation - must be updated appropriately and made into an informal or guidance section in an appendix

16. What are the modifications? (1) • Not limiting transmission of all STAs during CP to end before the start of CFP for all PHYs - Should be fixed in clause 9, doc#360. • Not limiting transmission of a polled STA to a duration as decided by PC - Should be fixed in clause 9, doc#360

17. What are the modifications? (2) • Removing the limitation on the maximum CFP duration to accommodate at least MaxMPDUTime in CP • Legacy STAs extend the CP by at least one DCF frame exchange time • Hence this limit only adds to the problem even when all the ESTAs are operating in CFP • Let EAP/EPC decide the duration of CFP and CP independent of this limit depending solely on amount of Qos-traffic and non-Qos traffic expected in both CFP and CP. • This limit must be modified to minimum size frame time. If a legacy station extends its transmission into CFP, the time taken for the frame exchange automatically makes the MaxMPDUTime limit.

18. What are the modifications? (3) • Removing normative text on polling list • The current polling list is an outdated and an hindrance to provide good Qos based on decisions made at EPC • Polling list must take into account the priorities of TC and number of such priority TCs from each ESTA. • According to the currently specified list processing rules, ALL (CF-pollable) STAs must be polled before polling the same STA again. If an (E)STA has more data to send while others don’t, this results in lot of bandwidth wastage in trying to poll all the (E)STAs before returning to the (E)STA with data. • According to the currently specified list processing rules, the polls must be done in the ascending order of AID. Given that an high priority traffic might start at any time during the QBSS life time, this is not applicable anymore.

19. What are the modifications? (4) • The proposed Qos mechanisms allow sophisticated schedulers to be used. • Hence it is proposed that the polling list creation, updation and processing clause (9.3) be appropriately modified and made informal or guideline material in an appendix rather than a normative clause.

20. What are the modifications? (5) • Making Flow-spec exchange mandatory for all traffic • Flow spec is an important piece of information that EAP/EPC can make use of during channel time allocation • Depending on the type of higher layer protocol used, this information may or may not be available at EAP/EPC. • Hence it is proposed that • The generic_action frame with flow spec be allowed to be sent by all ESTAs with a TC connection. • The EAP/EPC makes use of this information for allocation of Tx-ops • This merges the level-3 concept of parameterization of flows with the level-2 concept of prioritized channel allocation mechanism. And hence avoids one another level of Qos in 802.11e MAC.

21. Resolving issues in Qos-Tx-ops in the current Qos-baseline document- The Qos-Tx-op is defined as the Tx-op allocated using Qos-CF-poll, CF-multi-poll and CF-Sch frames

22. What are the issues? • There are five issues in Tx-op operation that needs to be fixed for proper Qos. The issues are related to, • Definition of non-final bit is ambiguous • lack of retry procedure • lack of procedure for EPC to take the left over Tx-op • Lack of indication of time for which data is pending at an ESTA • Use of Duration/ID field and use of CF-Ack • Lack of clarification on use of container frame • Use of sequence control for Qos-Null-data (no data) frames

23. What are the modifications? (1) • Remove Non-final bit from the header • Original proposal of Non-final bit was for scheduled transmissions and for the next ESTA in line for transmission to take over the channel • the generalization of use of this bit causes ambiguity and adds unnecessary complexity when the transmission opportunities are not scheduled • The problem gets worse when the frame containing Non-final-bit is not correctly received by the EAP/EPC • Hence it is proposed to remove the Non-final bit and let the EAP/EPC make use of the left over Qos-Tx-op as described later in this paper.

24. What are the modifications? (2) • Remove Override bit from the header • Introduces the complexity at ESTA that is having to change its queuing dynamically based on this bit • If the frame containing the Override bit is not correctly received at the ESTA in question, this can cause confusion and hence lead to collisions during CFP • Given that the EAP/EPC needs to plan the Qos-Tx-ops due to CF-Sch and CF-multi-poll ahead of time, the benefit of this is not evident. • Hence it is proposed to remove the override bit from the new header definition

25. What are the modifications? (3) • Procedure for retries during Qos-Tx-op • ESTAs must use PIFS to retry their frames, if required, during their own Qos-Tx-op • EAP/EPC must use DIFS (yes, it is DIFS!) to take over the channel when there is left over Qos-Tx-op time. The owner of Qos-Tx-op must recognize the channel getting busy after DIFS and must interpret that as the end of its Qos-Tx-op • Since EAP/EPC uses DIFS and the owner of Qos-Tx-op uses PIFS for retries, the channel access is contention free

26. What are the modifications? (4) • Rules for using the left over Qos-Tx-op • EAP/EPC must use DIFS to take over the channel when there is left over Qos-Tx-op time. • EAP/EPC can use the left over time in the current Qos-Tx-op for any time bound frame exchange as long as such an exchange does not cause any other already allocated Qos-Tx-ops to be violated. • An exception to this is EAP/EPC sending CF-Sch to terminate all the allocated scheduled Qos-Tx-ops Or reallocating unallocated time within CFP interval(s). • EAP/EPC must NOT nest CF-multi-polls (especially with second CF-multi-poll using left over Qos-Tx-op) that causes two Qos-Tx-ops for the same ESTA.

27. What are the modifications? (5) • Indication of “max elapsed time” for the TC • Each TC might have data pending for transmission for a while • EAP/EPC must provide preference to TC with the longest waiting frame for a given priority when allocating Tx-ops • Hence both RR frames and the Qos-MAC-Header must contain a field to indicate the “max elapsed time” to EAP/EPC

28. What are the modifications? (6) • Use Duration/ID field for Duration value in Qos-Data within CFP too • Within Qos-Tx-op the ESTAs must use Duration/ID field to indicate the duration till the end of their current Qos-Tx-op. Similar proposal has already been made for enhanced CC frame and transmissions during CCP. • Move the “special” contents of the Duration/ID field in Qos baseline proposal to a new field (along with the “max elapsed time” indication) as shown in the next slide

29. What are the modifications? (7) • The Qos-DATA Frame format Duration covering the Tx-op Modified TC ID field: Encoding of each field is described in the next slide

30. What are the modifications? (8) • Restrict the response frames to fit within the Qos-Tx-op of the ESTA that is initiating the frame exchange. • Since the “Dur/ID” field provides the information on end of Qos-Tx-op, the responding ESTA must be able to limit its transmission so as not to exceed the current Tx-op. • However, it is unfair for one ESTA to take another’s Qos-Tx-op. The owner of Qos-Tx-op or EPC will not be able to estimate the time required in the Qos-Tx-op properly! • Hence there has to be a bit in the data frames allowing or not allowing CF-Ack. The “Ack-policy” combination of ‘11’ (binary) for this purpose. That is, when the Ack-policy=‘11’, the responding station sends the control ‘ack’ frame as the response and does not send CF-Ack with its own data.

31. What are the modifications? (9) • Ack policy, Tx-op-limit and priority remain as it is defined in 360r1 • TC-SIZE is encoded in a non-linear fashion • TC-SIZE represents the time (not bits or bytes) as the only ESTA knows the PHY rate at which those bits are transmitted • TC-SIZE encoding is as follows: • values of [7-0] represents the requested time in the unit of 256 microseconds. Hence [0-1792] microseconds is represented • values of [8-15] represents the requested time in the unit of 384 microseconds. Hence [3072-5760] microseconds is represented • values of [16-31] represents the requested time in the unit of 512 microseconds. Hence [8192-15872] microseconds is represented • values of [32-63] represents the requested time in the unit of 1024 microseconds (TU). Hence [32-63] TUs is represented • Max-Elapsed-Time is encoded as TUs (0-32 TUs)

32. What are the modifications? (10) • Container frame must be treated like any other management frame • Normal-ack required. Ack can be avoided if the container frame is addressed to a group (multicast or broadcast), even though the frames may belong to only one ESTA. • No TCID field • Use sequence control from the same counter that is used by other management frames • Note that since management frames can transmitted in any priority range in the proposed CCP, container frames are not held back.

33. What are the modifications? (11) • Ignore Sequence control in Qos-Null-data (no data) frames • Qos-data frames use sequence control that is specific to each (SA, DA, priority) triplet. Qos-Null-data frames are dynamically constructed by the low-level entity that needs to be in the hardware for SIFS response time • Hence the sequence control for Qos-Null-data frames must be dynamically assigned and the succeeding frames in the queue are dynamically adjusted for their sequence control. OR all the sequence control counters must be maintained in hardware. This is an implementation nightmare! • At minimum, Qos-Null-data frames must use the same counter as the legacy frames to ease the implementation burden. But since the Qos-Null-data frames are not used in duplication detection and/or the delayed-ack mechanisms, the sequence control for these frames can as well be ignored.