MAC beaconing sync comment resolution September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 MAC beaconing sync comment resolution Date: 2010-01-19 Authors: Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Abstract Editorial comments Comments relatively easy to resolve September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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 Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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 Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Comments relatively easy to resolve September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 Comments relatively easy to resolve Done in 11-10/101 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 Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Comments relatively easy to resolve September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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/101 Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Comments relatively easy to resolve September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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 Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Comments relatively easy to resolve September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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 Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Comments requiring discussions September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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 Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Sync with STA outside the MBSS September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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. Placeholder Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Beacon timing information ambiguity September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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. Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

MLME-STARTBEACONING primitive September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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. Ask Harish to bring a proposal. Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 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. Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Summary Suggested resolutions to January 2010 September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 Summary Suggested resolutions to 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 are provided in 11-10/0099r0. These changes will be incorporated in 11-10/0101r0 as well. CID2004, 2006, 2036, 2719, 2789, 2026, 2029, 2037, 2043, 2044, 2720, 2019, 2010, 2011, 2505, 2519, 2025, 2033, 2051, 2192, 2722 will be provided in 11-10/0099r0 with a concrete text proposal submission 11-10/0101r0, once we reach consensus or nearly consensus. Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola

Comments? Questions? January 2010 September 2008 doc.: IEEE 802.11-08/1173r0 January 2010 Comments? Questions? Kazuyuki Sakoda, Sony Corporation Tony Braskich, Motorola