1. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 1 MAC beaconing sync comment resolution Date: 2010-01-19 Authors:

2. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 2 Abstract Editorial comments Comments relatively easy to resolve Comments requiring discussions –Sync with STA outside the MBSS –Beacon timing information ambiguity –MLME-STARTBEACONING primitive –A sort of wording, “TBTT Adjusting” or “TSF Adjusting” –Control bits in the Mesh Config element –Interaction with power save STA –Placeholder, Miscellaneous

3. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 3 Editorial comments CID2001, 2002, 2003, 2005, 2008, 2015, 2017, 2018, 2020, 2023, 2024, 2027, 2028, 2031, 2034, 2035, 2038, 2040, 2041, 2042, 2045, 2046, 2047, 2470, 2522, 2609, 2714, 2715, 2716, 2717, 2733, 2741, 2742 –Ask to correct the wording –Suggest to accept largely –Suggest to counter CID2008, 2034, 2046, 2714 with the similar text as suggested. –Suggest to reject CID2003, and 2047, because the original text is clear and does not need to be changed. –Suggest to defer CID2715, and 2741, because the resolution requires a new text with deep consideration. Done in 11-10/101

4. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 4 Comments relatively easy to resolve CID2004, 2006 –Complain about the structure of Beacon Timing (BT) element.  suggest to accept in principle. (resolution code: counter) This change does not affect any technical context. CID2036, 2719, 2789 –Complain about the content of the Neighbor STA ID field in BT element.  suggest to reject: the current definition is clear and useful. Do not need to be changed. CID2026, 2029, 2037, 2043, 2044, 2720 –Complain about the ambiguity of the Neighbor Last Beacon Time field in the BT element.  suggest to counter or reject: the Neighbor Last Beacon Time should contain the TBTT of neighbor STA’s. Text needs to be clear on this. Done in 11-10/101 Done in 11-10/101 Done in 11-10/101

5. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 5 Comments relatively easy to resolve CID2019 –Claim to remove clock drift compensation operation  suggest to reject: clock drift compensation is necessary. CID2010, 2011, 2505 –Point out the incompleteness of TBTT Adjustment primitive.  suggest to accept CID2505 in principle. Add request/confirm handshaking and describe the effect of the primitives more in detailed fashion. CID2519 –Suggest to add Beacon Timing report element in BSS description in the SCAN primitive.  suggest to accept in principle. It should be present actually. Done in 11-10/101 Done in 11-10/101 Done in 11-10/136

6. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 6 Comments relatively easy to resolve CID 2025, 2033, 2051, 2192, 2722 –Complain about the inconsistency among 11C.12.4 (Beacon Collision Avoidance) and X.3 (design rationale of MBCA).  suggest to accept CID2722 in principle. Merge X.3 to 11C.12.4 with a refined text. –A suggested new clause structure is shown in the next slide. Text will be provided accordingly

7. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 7 Comments relatively easy to resolve 11C.12.4.1 Overview Explain the overview, what problem MBCA is trying to solve. 11C.12.4.2 Beacon timing advertisement –11C.12.4.2.1 Transmitter’s procedure Explain how the beacon timing is advertised –11C.12.4.2.2 Transmitter’s procedure Explain how the receiver use this information. 11C.12.4.3 TBTT selection What shall be done before start beaconing 11C.12.4.4 TBTT adjustment –11C.12.4.4.1 Proactive adjustment Self adjustment according to the received BT element. –11C.12.4.4.2 Reactive adjustment Adjustment triggered by the TBTT Adjustment Request. 11C.12.4.5 Frame transmission acrossing reported TBTT Should not extend the transmission acrossing TBTT 11C.12.4.6 Delayed beacon transmission Optionally delay the beacon transmission. Done in 11-10/101

8. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 8 Comments requiring discussions CID2030, 2021 –Sync with STA outside the MBSS CID2718, 2009 –Beacon timing information ambiguity CID2521, 2638 –MLME-STARTBEACONING primitive CID2039, 2048 –A sort of wording, “TBTT Adjusting” or “TSF Adjusting” CID2032, 2049 –Control bits in the Mesh Config element CID2798, 2799 –Interaction with power save STA CID2050, 2258 –Placeholder CID2014, 2016, 2022, 2721 –Miscellaneous

9. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 9 Sync with STA outside the MBSS CID2030, 2021 –a mesh STA should synchronize only with peer mesh STAs MAC subgroup made some discussion on it at the previous comment resolution. It was suggested as following. –A suggestion: Mesh STAs shall track TSF of all the neighboring peer mesh STAs. Mesh STAs shall track TSF of neighboring non-peer STAs, if the request is issued by SME. Adhoc group agrees with above suggestion @PM2 Mon. Done in 11-10/101

10. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 10 Beacon timing information ambiguity CID2718 –Provide more accurate information when it is present. Especially when present in Probe Response frame is not provided. CID2009 –The Beacon Timing element can only hold beacon information of dot11MeshBeaconTimingReportMaxNum neighbors, and a maximum of 51 due to the length restriction of IEs. How is the case of (dot11MeshBeaconTimingReportMaxNum+n) and 52 or more neighbors handled? We should provide the text describing more accurate condition to close CID2718. Do we need to handle beacon timing of more than 51 neighbors? –A suggestion is to introduce “partial report” concept which is used in the MCCA advertisements. Adhoc group agrees to define the partial report method on BT element to leave more flexibility on the beacon timing reporting. @PM2 Mon. Placeholder

11. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 11 MLME-STARTBEACONING primitive CID2521 –MLME-STARTBEACONING can be merged with MLME-START with small changes. This will save lots of redundant text and will make it more consistent for BSS, IBSS and MBSS CID2638 –The primitive title "Start Beaconing" is vague and could be confusing. We may want to consider reusing MLME-START primitive. Need a coordination with mesh discovery clauses. Adhoc group agrees to reuse MLME-START primitive. @PM2 Mon. –Ashish provided a resolution text. Done in 11-10/135

12. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 12 Some more… CID2039, 2048 (“TBTT Adjusting” or “TSF Adjusting”) –“TBTT Adjustment” in D4.0 is actually adjusting TSF. It should called “TSF Adjustment”. –We should review the name of each operations… Adhoc group agrees to define them as a different operation. Keep the current name unless we come up with a better name. @PM2 Mon. CID2032, 2049 (Control bits in the Mesh Config element) –There is confusion with TBTT selection and TSF adjustments and corresponding bits in Mesh Capability field. The text describes the conditions for the selection of the TBTT and the procedure for adjusting the TSF. –We should review these control bits in Mesh Capability field… Adhog group agrees to make TSF Adjustment as mandatory and remove the control bit on it. @PM2 Mon. CID2798, 2799 (Interaction with power save STA) –Can TSF adjustment (TBTT Adjustment) be performed in the case of power save? If so, specify the procedure for TSF adjustment (TBTT Adjustment) for power save, so that the power save STAs can have correct timing information. Adhog group agrees that the sync and PM can work together and agrees to put some clarification text. @PM2 Mon. Placeholder Done in 11-10/101 Done in 11-10/101

13. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 13 Some more… CID2014 –The neighbor mesh STA's TSF timer value is not translated, it is actually the neighbor mesh STA's TSF timer value. The own TSF timer value will be translated. CID2016 –The TSF timer of a mesh STA is starte independently of other mesh STAs anyway, because it has to start the TSF timer before it can do any useful operation at all. A mesh STA should only update its TSF timer based on time stamps from peer mesh STAs (i.e. from the same MBSS). dot11MeshTbttSelectionActivated has nothing to do with updating the TSF timer. –Suggest to counter. The text is updated in 1-10/101. CID2022 –move 11C.12.3 to 11.1.2 (802.11-2007) –Suggest to reject. D4.0 has a pointer to 11C.12.3 in 11.1.2. This should be sufficient. CID2721 –Complains about the incompleteness of MBCA Needs some more work.

14. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 14 Summary Suggested resolutions to –CID 2004, 2006, 2010, 2011, 2016, 2021, 2022, 2025, 2026, 2029, 2030, 2033, 2037, 2038, 2039, 2043, 2044, 2048, 2051, 2192, 2505, 2720, 2722, 2798, 2799, 2001, 2002, 2003, 2005, 2008, 2015, 2017, 2018, 2019, 2020, 2023, 2024, 2027, 2028, 2031, 2034, 2035, 2036, 2040, 2041, 2042, 2045, 2046, 2047, 2470, 2609, 2714, 2716, 2717, 2719, 2733, 2742, and 2789 are provided in 11-10/0099r2. These changes are incorporated in 11-10/0101r2 as well.

15. doc.: IEEE 802.11-10/0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 15 Comments? Questions?