Suggested comment resolution on MDA Access Fraction (MAF) March 2007 Suggested comment resolution on MDA Access Fraction (MAF) Date: 2007-03-15 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 March 2007 Outline Overview of MDA Overview of MAF Problems and questions regarding MAF Suggested resolution Michelle Gong, Cisco

March 2007 MDA enables scheduled transmissions between synchronized MPs in a distributed fashion 2 7 1 5 6 10 9 8 3 4 MDAOP is the basic building block of MDA (It is not a TXOP) MDAOP is a period of time within every mesh DTIM interval that is set up between a transmitter and a receiver After a pair of nodes set up a MDAOP, they include the MDAOP timing information in an MDAOP Advertisement Element All neighbouring MDA devices shall refrain from transmitting during the duration of the MDAOP The MDAOP Advertisement IE can be sent in either beacons or broadcast action frames It contains the start and end information of MDAOPs at the current MP and MDAOPs information at its one-hop neighbors Michelle Gong, Cisco

Contention and collisions can still occur within each MDAOP March 2007 Contention and collisions can still occur within each MDAOP MDA devices need to coordinate in a distributed fashion to get the MDAOP information within their interference range They 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) Depending on Tx power, radio propagation loss, receiver sensitivity, etc., interference can easily go beyond one-hop It is unknown how MDAOP scheduling could work when there are overlapping MDA networks Further, non-MDA devices do not understand MDAOP Michelle Gong, Cisco

One MDA TXOP is set up within each MDAOP March 2007 One MDA TXOP is set up within each MDAOP An MDA TXOP is a TXOP as defined in 11e After setting up an MDAOP, an MDA device needs to contend to set up an MDA TXOP During the MDA TXOP, all devices, including both MDA devices and non-MDA devices, refrain from transmitting MDA TXOP Node 1 Node 2 MDAOP 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 at the expense of non-MDA networks or overlapping MDA networks 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 associated with MAF March 2007 There are some problems associated with 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 for 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 MAF-related comments: CID 1531, 1626, 4282, and 4656 Michelle Gong, Cisco

Many questions remain to be answered March 2007 Many questions remain to be answered How to co-ordinate overlapping MDA networks with MAF limits? 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?) Michelle Gong, Cisco

March 2007 Instead of using MAF, MDAOP limits and MDA TXOP limits should be defined Four MDAOP limits for 4 ACs Currently, MDAOP does not consider traffic QoS requirements Neighbouring MDA devices remain silent 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 “MAF” and “MAF 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

March 2007 Straw Poll 802.11 devices should share unlicensed medium in a fair way? Yes No Don’t care Michelle Gong, Cisco

Straw Poll Mandate TXOP limits on MDA devices? Yes No Don’t care March 2007 Straw Poll Mandate TXOP limits on MDA devices? Yes No Don’t care Michelle Gong, Cisco