Synchronization related comment resolution September 2008 Synchronization related comment resolution Date: 2008-09-09 Authors: Kazuyuki Sakoda

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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