1 / 15

MDA Comment Resolution

MDA Comment Resolution. Date: 2009-19-01. Authors:. Resolve a number of CIDs on MDA.

odysseus-carr
Download Presentation

MDA Comment Resolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MDA Comment Resolution Date: 2009-19-01 Authors: Dee Denteneer, Philips

  2. Resolve a number of CIDs on MDA CIDs: 252, 282, 314, 315, 318, 319, 321-323, 527, 528, 530, 618, 622, 631, 632, 726, 752, 755-757, 843, 844, 948, 1133, 1134, 1181, 1183, 1335, 1482, 1484, 1581, 1744, 1821, 1846, 1876, 1877, 1878, 1880, 1954, 1955 This presentation describes some grouping of the proposed comments and their resolution. For details we refer to the Normative text: IEEE 802.11-09/0154r0; the excel sheet describing all the comment resolution is 11-09/0153r0 Dee Denteneer, Philips

  3. CIDs: 282, 314, 318, 1181, 1183, 1744, 1821, 1846, 1954, 1955 • “Mesh Deterministic Access (MDA) is an optional access method. If only part of fhe MP will support this method and the other will not the overall performance may be poor. So leaving the feature optional makes it useless” so “Make the feature mandatory or remove it” • Reject: “It is not possible to guarantee an environment with MDA enabled stations only, due to the existence. However, this is It is not necessary either, as contribution 11-07-0356-00-000s shows that there is still considerable gain in efficiency also when there are a number of non-MDA interfering stations present.” Dee Denteneer, Philips

  4. CIDs: 1484 • “1/16 is a very large fraction in some deployments” (for MAF. • Counter: “Basically accept, Increased size to 8 bits and expressed as a fraction of the MAF Limit, see Clause 7.3.1.42 contribution 11-08-xxxx-00-000s.” Dee Denteneer, Philips

  5. CIDs: 752, 756, 757 • “Since MPs do their own beaconing there is no mesh beacon and no mesh TIM and no mesh DTIM. - the rules for TIMs and DTIMS are the same for APs and for MPs.. • Reject: Draft 2.05 now gives a proper definition of mesh TIM etc, see Clause 11B12.5. Dee Denteneer, Philips

  6. CIDs: 618, 726, 948 • “Clarify. Suggest to add a text desribing the rule what the MDA active MP shall perform with power management related mechanisms.” • Such a section is now available in the Drfat 2.06, see Clause11B12.11 • MDA enabled MPs shall not go to deep sleep. • Address this. Dee Denteneer, Philips

  7. CIDs: 315, 319, 321, 323, 755 • “In order to use the MDA method for access, an MP shall maintain synchronization with its neighboring MP." This seems to be contradictory to the fact that mesh synchronization protocol is neither required nor specified in the spec. ” • The relation between MDAOP and synchronization has been clarified in the Draft 2.06. Dee Denteneer, Philips

  8. CIDs: 632, 1581 • “The setence reads: "A tear down shall be initiated when either MDAOP owner or receiver lean of a conflicting MDAOP set from an advertisement by a neighbor with a lower MAC address". Is it a fair rule that the MP which has a lower MAC address always has a privilege?” • Reject because “The situation is an exceptional one. Fairer tie breaking rules are possible, but would most likely require more signalling and protocol overhead. Therefore, the proposed tie breaking rule is considered to be an acceptable compromise.” Dee Denteneer, Philips

  9. CIDs: 528, 1133, 1134, • “The MDAOP Advertisement Request frame will be transmitted in an action frame only to its MP peers. One-hop neighbors, may not be peers. To send this action to them, it will be necessary to forward this action frame more than one hop. Therefore, this action frame should be a multihop action frame.” • Reject because “Advertisements can be communicated to non-peer neighbors via Beacons. Also, it is possible to establish a peer link if this is needed; hence it is not necessary to achieve this via multihop action frames and this is not desirable either, as it causes additional overhead.” Dee Denteneer, Philips

  10. Remaining comments: 1878, 1880 • “"MDA-supporting MPs shall track Neighborhood MDAOP times" There is no bound on the amount of state required to do this. What happens if a STA can see 10,000 different MDAOP times? Is it required to track them all? “Specify a minimum number of times that must be tracked.” Follow up on this one by introducing a MIB variable dot11MDAOPTrackLimit. Also mandate that a mesh STA that has reached this limit can no longer act in an MDAOP as either owner or responder. Add a reason code for rejecting the setup request. Dee Denteneer, Philips

  11. Remaining comments: CIDs:1036, 1310, 1434 • “Change the name of MDA, after all, there is nothing deterministic to it. A good name would be MCF (for mesh coordination function).” • Still waiting for the instant of creative inspiration: MCCA, underneath MCF. Specify replacement and give some some additional phrases that must be changes. Check difference between function and access Dee Denteneer, Philips

  12. Comments: 252 • “It is not necessary to specify as a NAV behavior. NAV is started by receiving a frame (whose DA is not the STA's MAC address). Here, the STA is not receiving a frame and it is different from the ordinary NAV setting. “ • Accept: removed the reference to NAV setting, also see next slide. Dee Denteneer, Philips

  13. Remaining comments: 100, 529, 635, 636 • “The draft says that "All MDA supporting MPs other than the MDAOP owner shall defer initiating transmissions during theTXOP initiated in the MDAOP." What defer mechanism should be used and what is the defer time? If the mechanism is up to the implementation, it is difficult to get fairness among MPs other that MDAOP owner. • Should defer for MDAOP Duration. The reason for the comment seems to lie with the use of the word defer. Dee Denteneer, Philips

  14. Remaining comments: 399, 1956 • “Non-MDAOP owners defer during the TXOP started during the MDAOP. But what happens if no TXOP starts? No other communications are possible at this time (i.e. 9.21.9.1 suggests that MDA stations must set a NAV outside of their own MDAOP). This implies very inefficient use of medium time.” I intend to mandate a transmission in an MDAOP. This can be a QoS null frame CF-end exchange with timing set for a transmission of length 0, just to release the MDAOP CF End CF End 11n: 9.1.5.5.a2; check draft 1.0 Dee Denteneer, Philips

  15. Remaining comments: 1182 • “How tight does the timing/synchronization need to be between MP's for the MDAOP start times and durations to be meaningful? Is such timing/synchronization achievable?” • This still needs consideration. Dee Denteneer, Philips

More Related