Suggested comment resolution on MDA Access Fraction (MAF) March 2007 Suggested comment resolution on MDA Access Fraction (MAF) Date: 2007-03-13 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Michelle Gong, Cisco

Outline Overview of MDA Overview of MAF Some comments related to MAF March 2007 Outline Overview of MDA Overview of MAF Some comments related to MAF Suggested resolution Michelle Gong, Cisco

March 2007 MDA enables scheduled transmissions between synchronized MPs in a distributed fashion After a pair of nodes set up a MDAOP, they include the MDAOP timing information in a MDAOP Advertisement Element All neighbouring MDA devices shall refrain from transmitting during the duration of the MDAOP The MDAOP Advertisement element contains MDAOP start and end information TX-RX Time Report for the current MP Interfering Time Report from its neighbors MDA devices need to coordinate in a distributed fashion to get the MDAOP information within their interfering range 9 6 MDAOP: a period of time within every mesh DTIM interval that is set up between a transmitter and a receiver 8 2 7 10 TX-RX Time Report: The time in the Mesh DTIM interval when the MP is busy as a transmitter or receiver 1 5 3 4 Michelle Gong, Cisco

There is confusion on why both MDAOP and MDA TXOP are needed March 2007 There is confusion on why both MDAOP and MDA TXOP are needed Mesh APs do not always have a consistent and accurate view of the MDAOP distribution New MDAOPs can be set up at any time Beacons and broadcast action frames may not be delivered reliably or in a timely fashion Perfect scheduling is difficult to achieve because there is no centralized control entity in a mesh network (Distributed scheduling is a NP-Hard problem) New MDAOP setup within the same interval may overlap with each other Further, legacy devices do not understand MDAOP Thus, an MDA TXOP has to be set up within each MDAOP MDA TXOP Node 1 Node 2 MDAOP MDAOP: MDA Opportunity MDA TXOP: a TXOP as defined in 11e Michelle Gong, Cisco

The use of MDAOP at each MP is constrained by a MAF limit March 2007 The use of MDAOP at each MP is constrained by a MAF limit A parameter called MDA access fraction (MAF) is defined to limit the use of MDA in a neighborhood to a certain fraction of the total channel time To prevent MDA-enabled networks from gaining unfair access to the medium To prevent one MDA device from capturing the medium for a prolonged time such that its own and other MPs’ higher priority traffic, i.e. mesh management frames, voice and video, is negatively impacted Upon receiving an MDAOP set up request, an MP is required to make sure that the new MDAOP set does not cause the MAF of any of its neighbors to exceed its MAF limit Michelle Gong, Cisco

There are some problems and questions regarding MAF March 2007 There are some problems and questions regarding MAF The complexity for checking and maintaining MAF is high An MP needs to keep a record of each of its neighbors’ MAF limit and calculate the combined MDAOP timing information of each of its neighbors The scheme to predict whether the new MDAOP set up will exceed MAF limits at neighbors can be unreliable The MDAOP information of its neighbors may not be up to date MAF does not differentiate access categories When MAF is shared among all neighbors and for all traffic types, it is unclear how QoS can be achieved How to determine MAF limits such that fair medium sharing can be achieved between MDA and other medium access methods, for instance, EDCA? How is MAF limit coordinated among neighboring MPs? (For instance, if one device sets a low or zero MAF limit, what will its neighbors do?) MAF-related comments: CID 1531, 1626, 4282, and 4656 Michelle Gong, Cisco

Instead of using MAF, MDAOP limits and MDA TXOP limits can be defined March 2007 Instead of using MAF, MDAOP limits and MDA TXOP limits can be defined Four MDAOP limits for 4 ACs Currently, MDAOP does not consider traffic QoS requirements Neighbouring MDA devices refrain from transmitting during the duration of an MDAOP, regardless of whether they have mesh management frames or voice packets To ensure timely delivery of management frames and to differentiate QoS traffic, an MDAOP needs to adopt the same AC as the traffic being delivered in the MDAOP Four MDA TXOP limits for 4 ACs All non-MDA devices need to remain silent during the duration of MDA TXOP regardless of their traffic classes Setting large MDA TXOPs grant unfair access to MDA devices and affects the traffic on non-MDA devices negatively Michelle Gong, Cisco

March 2007 Suggested Resolution Replace section 9.14.6 MDA Access Fraction (MAF) with the following text 9.14.6 MDAOP Limit and MDA TXOP Limit An MDAOP limit is a time limit on a MDAOP. An MDAOP begins a SIFS period after an MDAOP is set up, indicated by the reception of an MDAOP Setup Reply message, and lasts no longer than the number of 32us specified by the MDAOP limit. The range of time values is 32us to 8160us. The MDA TXOP limit is the same as the TXOP limit defined in section 7.1.3.5.4. The values of MDA TXOP limits are the same as those defined in Table 37. Michelle Gong, Cisco

March 2007 Suggested Resolution Remove the text related to “MFA” and “MFA limit” from section 7.3.2.58 and section 9.14 Modify the text related to MDAOP Setup request and MDAOP Setup reply in section 7.3.2 to reflect the traffic AC of each MDAOP Michelle Gong, Cisco