1. Synchronization related comment resolution
September 2008
Synchronization related comment resolution
Date:
Authors:
Kazuyuki Sakoda

2. September 2008
Abstract
The following slides present the suggested resolution to some of the CIDs relating to synchronization.
Clarification on beacon timing element field and the usage of fields. (CID698, 1333, 1534, 1446)
Clarification on the flexibility and optionality of the synchronization protocol. (CID694, 901, 939, 941, 942, 943, 976, 978, 979, 1717, 1720)
Specifying detailed rule for TBTT adjustment to avoid confusion or instability. (CID 332, 625, 696, 703, 1929)
Kazuyuki Sakoda

3. September 2008
Recap: MBCA rationale
MBCA (Mesh Beacon Collision Avoidance) is designed to provide a tool to avoid continuous collision of beacon frames from hidden nodes.
Hidden node is not a corer case problem in mesh environment.
MP-A
MP-B
MP-C
Collision is observed when MP-A and MP-C transmit a frame at the same time.
This collision is observed only at MP-B if MP-A and MP-C are out of range each other.
Kazuyuki Sakoda

4. Recap: MBCA rationale (Cont’d)
September 2008
Recap: MBCA rationale (Cont’d)
Collision between beacon frames
Unlike most of other frames, beacon frames are transmitted periodically.
Hence, the beacon collision will be repeated continuously if both of the beacons are transmitted at the same beacon interval. TX RX TX RX TX RX
MP-A
time RX TX RX TX RX TX
MP-B
time TX RX TX RX TX RX
MP-C
time
Kazuyuki Sakoda

5. Recap: MBCA rationale (Cont’d)
September 2008
Recap: MBCA rationale (Cont’d)
D2.01 defines an optional “Mesh Beacon Collision Avoidance”, using beacon timing advertisement
Step1: MP-B records the reception timing of beacons from its neighbors (MP-A and/or MP-C), and report it through beacon timing element.
Step2: MPs receiving beacon timing element can get a timing information of periodic interference source. MP-A and MP-C is informed when they should not transmit beacon frames (when MP-B is receiving beacon frames).
MP-A
MP-B
MP-C
Kazuyuki Sakoda

6. Comments on beacon timing element
September 2008
Comments on beacon timing element
CID 698, 1333, 1534:
Ask for the clarification which type of beacons are carried through the beacon timing element.
CID1446:
Ask for the clarification how the AID field in the beacon timing element will be used.
Kazuyuki Sakoda

7. Suggested resolution CID 698, 1333, 1534: CID1446:
September 2008
Suggested resolution
CID 698, 1333, 1534:
Ask for the clarification which type of beacons are carried through the beacon timing element.  All of the beacon frames could be contained in the beacon timing element, since the beacon collision problem occurs regardless of the beacon frame types. Add some more description in subclause within 11B.12.5.
CID1446:
Ask for the clarification how the AID field in the beacon timing element will be used.  AID value is used to check if my beacon is received properly at the receiver. Add some more description in subclause within 11B.12.5.
Kazuyuki Sakoda

8. September 2008
Comments on flexibility and optionality of the synchronization protocol
CID 694, 1720
Ask for the text refinement
CID 901
Neighbor offset protocol should be the only sync protocol
CID 939, 941, 943, 976, 978, 979
Neighbor offset protocol should be the mandatory protocol
CID 942
Ask for the definition what is meant by “synchronization”
CID 1717
Ask for the clarification how an MP handles different synchronization protocols.
Kazuyuki Sakoda

9. According to the current draft spec
September 2008
According to the current draft spec
“An extensible framework is introduced to enable flexible implementation of synchronization protocols neighbor offset synchronization protocol is defined to enable minimal synchronization capability and interoperability ... To accommodate various application needs, the framework allows flexibility to integrate future synchronization protocols ... ”
My understanding is …
Synchronization is defined as an extensive framework just like routing protocol.
Neighbor offset protocol is defined as a default protocol just like HWMP.
Vendors can implement other sync protocols if they want to. Sync protocol other than neighbor offset is beyond the scope of the standard.
Kazuyuki Sakoda

10. September 2008
Suggested resolution
If we would like to keep the optionality and flexibility of the sync protocol in the D2.01…
Keep the current framework approach.
Keep the neighbor offset protocol as default but optional protocol.
Refine the text to make the text more reader friendly.
If TG members feel it is not necessary to define framework…
We should change the framework.
If TG members feel it is better to make neighbor offset protocol mandatory…
We should change the optionality of this protocol.
Kazuyuki Sakoda

11. September 2008
Suggested resolution
MAC group discussed these issues, on Monday evening, and it was generally agreed :
Keep the current framework approach.
Make the neighbor offset protocol as default and mandatory protocol in order to preserve a better interoperability. Just like HWMP as a routing protocol.
Kazuyuki Sakoda

12. Comments on TBTT adjustment
September 2008
Comments on TBTT adjustment
CID 332
Adjusting mesh beacon TBTT can cause unsynchronization of MPs in power save mode. Explain the impact and provide remedy.
CID 625, 696
Concerns about clock drifting impact for PS and MDA
CID 703, 1929
TBTT adjustment rule is too vague and concerns about the stability of the adjustment algorithm.
Kazuyuki Sakoda

13. Suggested resolution According to the draft spec D2.01,
September 2008
Suggested resolution
According to the draft spec D2.01,
“Options an MP has for adjusting its TSF include advancing or suspending the TSF for a period of time.”
MP can do whatever it want to in adjusting TSF.
Suggest to restrict the adjustment option with some rules:
Suspend TSF timer to combat the TBTT drifting, resulting in slowing its clock direction.
When MP discovers beacon collisions by itself, MP which has the higher MAC address slows the TBTT. (as suggested by CID1929)
When MP receives TBTT adjustment request, it slows the TBTT.
Rationale : TBTT adjustment is operated to slowing the clock direction, so that other PS MP do not miss the frame reception.
Kazuyuki Sakoda

14. September 2008
Summary
Suggested to provide the more detailed description how the beacon timing element is used.
Suggested to provide the more explicit description on the synchronization frame work and the optionality of the neighbor offset protocol.
Suggested to restrict in adjusting TBTT so that the power saving MP can keep track of adjusting MP’s TBTT.
The proposed text is provided in 11-08/1073r1.
Kazuyuki Sakoda

15. September 2008
References
[1] Draft Amendment Mesh Networking: IEEE P802.11s /D2.01, July 2008.
[2] doc.: IEEE /0493r18 “Letter Ballot 126 Comment Resolutions“
[3] doc.: IEEE /1073r1 “Synchronization related comment resolution, BTE, Neighbor Offset, MBCA“
Kazuyuki Sakoda

16. September 2008
Strawpoll (1)
Do you think it is reasonable to provide more detailed description on becon timing elment as explained in the earlier slides?
Yes:
No:
Do not care:
Kazuyuki Sakoda

17. September 2008
Strawpoll (2)
Which approach do you prefer for the mesh synchronization flexibility?
Keep the framework approach to allow other implementation in the future:
Define a solid sync protocol to assure the interopelability:
Do not care:
Kazuyuki Sakoda

18. September 2008
Strawpoll (3)
Which optionality do you prefer for neighbor offset protocol?
Define the neighbor offset protocol as a mandatory sync protocol:
Keep the neighbor offset protocol as a default but optional protocol:
Do not care:
Kazuyuki Sakoda

19. September 2008
Strawpoll (4)
Do you think it is reasonable to define more detailed rules for adjusting MP‘s TBTT as explained in the earlier slides?
Yes:
No:
Do not care:
Kazuyuki Sakoda

20. September 2008
Strawpoll (5)
Do you think it is reasonable to adopt the resolutin text prposed in 11-08/1073.r0 ?
We should accept the text as it is:
We should accept the text with some amendment:
We should look for completely other resolutions:
Kazuyuki Sakoda