1 / 19

Synchronization related comment resolution

Synchronization related comment resolution. Date: 2008-09-08. Authors:. 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)

dinah
Télécharger la présentation

Synchronization related comment resolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Synchronization related comment resolution Date: 2008-09-08 Authors: Kazuyuki Sakoda

  2. 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. 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. 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. 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 • 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: • 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. 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 • “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. 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. 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

  12. 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, in slowing the reference timing 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 reference timing direction, so that PS MP can keep track the timing. Kazuyuki Sakoda

  13. 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/1073r0. Kazuyuki Sakoda

  14. 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/1073r0 “Synchronization related comment resolution, BTE, Neighbor Offset, MBCA“ Kazuyuki Sakoda

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

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

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

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

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

More Related