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
March 2007
Outline
Overview of MDA
Overview of MAF
Problems and questions regarding MAF
Suggested resolution
Michelle Gong, Cisco

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

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

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

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

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

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

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

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

11. March 2007
Suggested Resolution
Remove the text related to “MAF” and “MAF 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

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

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