MAC beaconing sync comment resolution

1. MAC beaconing sync comment resolution Authors: Date: 2010-01-19 Kazuyuki Sakoda, Sony Corporation

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 Kazuyuki Sakoda, Sony Corporation

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 Kazuyuki Sakoda, Sony Corporation

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

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/101 Kazuyuki Sakoda, Sony Corporation

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 Kazuyuki Sakoda, Sony Corporation

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 Kazuyuki Sakoda, Sony Corporation

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 Kazuyuki Sakoda, Sony Corporation

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. Placeholder Kazuyuki Sakoda, Sony Corporation

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. Kazuyuki Sakoda, Sony Corporation

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. • Ask Harish to bring a proposal. Kazuyuki Sakoda, Sony Corporation

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. Kazuyuki Sakoda, Sony Corporation

13. 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, 2742are provided in 11-10/0099r0. These changes will be incorporated in 11-10/0101r0 as well. • Suggested resolutions to • CID2004, 2006, 2036, 2719, 2789, 2026, 2029, 2037, 2043, 2044, 2720, 2019, 2010, 2011, 2505, 2519, 2025, 2033, 2051, 2192, 2722will 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

14. Comments? Questions? Kazuyuki Sakoda, Sony Corporation