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

2. Abstract Editorial comments Comments relatively easy to resolve
September 2008
doc.: IEEE /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

3. September 2008
doc.: IEEE /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

4. Comments relatively easy to resolve
September 2008
doc.: IEEE /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

5. Comments relatively easy to resolve
September 2008
doc.: IEEE /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

6. Comments relatively easy to resolve
September 2008
doc.: IEEE /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

7. Comments relatively easy to resolve
September 2008
doc.: IEEE /1173r0
January 2010
Comments relatively easy to resolve
11C Overview
Explain the overview, what problem MBCA is trying to solve.
11C Beacon timing advertisement
11C Transmitter’s procedure
Explain how the beacon timing is advertised
11C Transmitter’s procedure
Explain how the receiver use this information.
11C TBTT selection
What shall be done before start beaconing
11C TBTT adjustment
11C Proactive adjustment
Self adjustment according to the received BT element.
11C Reactive adjustment
Adjustment triggered by the TBTT Adjustment Request.
11C Frame transmission acrossing reported TBTT
Should not extend the transmission acrossing TBTT
11C Delayed beacon transmission
Optionally delay the beacon transmission.
Done in
11-10/101
Kazuyuki Sakoda, Sony Corporation
Tony Braskich, Motorola

8. Comments requiring discussions
September 2008
doc.: IEEE /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

9. Sync with STA outside the MBSS
September 2008
doc.: IEEE /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 Mon.
Placeholder
Kazuyuki Sakoda, Sony Corporation
Tony Braskich, Motorola

10. Beacon timing information ambiguity
September 2008
doc.: IEEE /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 Mon.
Kazuyuki Sakoda, Sony Corporation
Tony Braskich, Motorola

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

12. September 2008
doc.: IEEE /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 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 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 Mon.
Kazuyuki Sakoda, Sony Corporation
Tony Braskich, Motorola

13. Summary Suggested resolutions to January 2010
September 2008
doc.: IEEE /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

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