1. Suggested comment resolution on MDA Access Fraction (MAF)
March 2007
Suggested comment resolution on MDA Access Fraction (MAF)
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Michelle Gong, Cisco

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. March 2007
Suggested Resolution
Replace section MDA Access Fraction (MAF) with the following text
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 The values of MDA TXOP limits are the same as those defined in Table 37.
Michelle Gong, Cisco

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