190 likes | 350 Vues
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)
E N D
Synchronization related comment resolution Date: 2008-09-08 Authors: Kazuyuki Sakoda
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
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
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
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 • 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: • 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
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 • “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
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
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, • “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
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
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
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
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
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
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
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