Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 1 MAC beaconing sync comment resolution Date: 2011-01-20 Authors:

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 1 MAC beaconing sync comment resolution Date: 2011-01-20 Authors:"— Presentation transcript:

1 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 1 MAC beaconing sync comment resolution Date: Authors:

2 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 2 Abstract Overview Comments relatively easy to resolve Comments planned to be resolved Comments requiring discussions

3 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 3 Overview 166 comments under M-BS category Further detailed categorization under M-BS –BT element extension: BT element naming: –BT element procedure:Clock drift: –Delayed beacon transmission:doc struture: –extensible framework: –MIB:MLME: –Report Status subfield:status code: –sync protocol:omission: –Wording:

4 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 4 Overview –BT element extension: –BT element naming: –BT element procedure: –Clock drift: 1259 –Delayed beacon transmission: 1237 –doc structure: –Extensible framework: 1268 –MIB: –MLME: –Report Status subfield: 1213 –Status code: 1190 –Sync protocol: –Omission: –Wording: Rest of the comments

5 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 5 Comments relatively easy to resolve Wording, omission, MIB, delayed beacon transmission: – –Ask to provide a better text Suggested resolutions are available in 11-11/99r0 and r0.

6 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 6 Comments planned to be resolved Need some more time to think and come up with a potentially better text Wording: – MLME: – Extensible framework: –1268 Status code: –1190

7 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 7 Comments requiring discussions sync protocol: Clock drift: BT element extension: BT element naming: doc structure: MIB: BT element procedure: Report Status subfield:

8 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 8 Sync protocol CID1274: –A BSS uses a timing synchronization function, not a synchronization protocol. –Change "... indicates the synchronization protocol that is..." into "... indicates the timing synchronization function that is...", check throughout draft as well. Synchronization Protocol in terms of framework Neighbor Offset Synchronizationin terms of the default protocol for synchronization protocol framework.

9 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 9 Clock drift CID1259: The beauty of the Neighbor Offset protocol is its simplicity due to its restriction to a single link or in other words, its per neighbor scope, i.e. each neighbor is considered completely independent. No chain reactions in the multihop environment. By the way, this property of independet neighbor offsets is the main reason, that the Neighbor Offset protocol is acceptable as the mandatory default synchronization protocol. The clock drift adjustment which is proposed in 11C , however, breaks this property. It will lead to chain reactions in the complete mesh BSS. The goal of the Neighbor Offset protocol is to know the TSF timer of the neighbor mesh STA. TBTT drifting is not in this scope. Remove clause 11C Clock drift compensation should be done in MBCA and in MCCA and in power management independently? Clock drift compensation is useful.

10 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 10 BT element extension Make the Beacon Timing element extensible –insert a field Beacon Timing Information Count … The Neighbor Last Beacon Time field can only express the time up to seconds. However, the maximum beacon interval is 65,535 TU and is larger than the maximum value in the Neighbor Last Beacon Time field. Do we want to extend the BT element ? BT element should handle the longest beacon interval. Extensible for what? No idea so far. Maybe we do not need to make it extensible.

11 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 11 BT element naming "Neighbor Last Beacon Time subfield" "Neighbor TBTT subfield" agreed!! "More Report "More Beacon Timing Elements "More Beacon Timing Elements subfield" "Report Number subfield" "Index Number subfield Beacon Timing Element Number subfield agreed!! "Report Status subfield "Status Number subfield" agreed!!

12 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 12 doc structure CID1279 –move 11C.12.1 to and change title into "TSF for an MBSS –- remove last paragraph (lines 49-50) because they are implicit if this clause is in CID1282 –An uncited definition in IEEE says: "A Timing Synchronization Function (TSF) keeps the timers for all STAs in the same BSS synchronized. All STAs maintain a local TSF timer." This is also applicable for the mesh BSS, but it is somehow different from the text defined in 11s. Put something both in clause 11 and 11C.

13 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 13 MIB CID1234: –The average duration of the last 16 received beacons is not expected, it is known. How can I compute something that happened at a neighbour but not at the mesh STA? How about if different neighbours have quite different beacon reception times due to different data rates? If it is neighbor specific, it should not be in the MIB. –Provide a correct description of dot11MeshAverageBeaconFrameDuration. If it is neighbor-specific, remove it from the MIB. The MIB description needs to be refined. dot11MeshAverageBeaconFrameDuration will be an approximation at the mesh STA, computed locally.

14 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 14 BT element procedure In 11C , The note does not make so much sense. Firstly, it is incomplete, because the Report Control field with all its fields is necessary to detect missing beacon information. Secondly, the mesh STA will retrieve all other beacon timing elements already after the first beacon timing element of a new status number, because the status number had changes. In 11C , It is not clear how to signal the deleted TBTT using the Beacon Timing element. Remove Report Status subfield in the in NOTE. If the Report Status value remains the same as indicated in the previously received Beacon Timing element, the mesh STAs do not need to retrieve all the beacon timing information. It is applicable only when the mesh STA already has entire beacon timing information indexed with that number

15 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 15 Report Status subfield CID1213: –Why and how can the Report Status subfield in the Report Control field in the Beacon Timing element be used to distinguish a large TSF jitter from a TBTT adjustment? I think this is not possible, because there are also other things than the TBTT adjustment that change the status number. Suggested resolution –Although the Report Status subfield is updated per the update of the beacon timing information as well as the completion of the TBTT adjustment, it is still helpful for mesh STAs in deep sleep mode that do not listen to neighbor peer mesh STA's beacons. It is true that the neighbor mesh STA may misinterpret the update of the Report Status field. However, it only occurs when the neighbor peer mesh STA observes large TSF jitter. Also, the effect of the misinterpretation is limited and only affect to the safe side. If it happens, the neighbor peer mesh STA do not operate the clock drift compensation and (usually) try to listen to the next beacon to see if the clock drift is large. The decision can be made according to these observations. –Alternatively, we may want to define two Report Control field. (one is for beacon timing update, another is for TBTT adjustment execution) Amend the note to say that when Report Status is changed TBTT adjustment might be operated. Thus in such case, the mesh STA should observe further beacon reception timing …

16 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 16 Further discussion

17 doc.: IEEE /0101r4 Submission January 2011 Sync protocol On framework level term: –Synchronization Protocol Identifier / active sync. protocol –Some options to consider: #1: synchronization protocol as defined currently # 2: synchronization mode # 3: synchronization method Anything else? Neighbor Offset Protocol: –Some options to consider: #1: Neighbor Offset Protocol, as defined currently #2: Neighbor Offset Synchronization #3: Neighbor Offset #4: Neighbor Offset Synchronization method

18 doc.: IEEE /0101r4 Submission January 2011 Sync protocol Strawpoll: –Which option do you prefer for framework? #1: synchronization protocol: 1 # 2: synchronization mode: 1 # 3: synchronization method: 4 –Which option do you prefer for Neighbor Offset Protocol? #1: Neighbor Offset Protocol : 0 #2: Neighbor Offset Synchronization: 1 #3: Neighbor Offset : 0 #4: Neighbor Offset Synchronization method: 3

19 doc.: IEEE /0101r4 Submission January 2011 BT element extension How we extend the beacon timing expression? Some options to consider: –Change the precision of the unit : 256usec TU –Change the length of Neighbor TBTT subfield 2octets 3octets –Insert a new field to signal the precision of the unit: The precision is defined by the setting of the new field. (i.e., 256 usec or TU) –Anything else?

20 doc.: IEEE /0101r4 Submission January 2011 BT element extension Strawpoll: –Which option do you prefer? Change the precision of the unit : 256usec TU: 0 Change the length of Neighbor TBTT subfield 2octets 3octets: 4 Insert a new field to signal the precision of the unit: The precision is defined by the setting of the new field. (i.e., 256 usec or TU) : 0 32 usec unit is treated as a unit for (TXOP size) in QoS STA. it might be good idea to adopt them. –Which value do you prefer to define as the precision of the BT timing. 256:: 1 32:: 3

21 doc.: IEEE /0101r4 Submission January 2011 Clock drift What is the most preferable way to go? –Leave the clock drift to outside the scope.: 0 –Define the clock drift compensation to be a part of synchronization, as defined currently.: 3 –Define the clock drift compensation independently in power save, MCCA, and MBCA.: 0 –Define clock drift compensation as separate clause reference if needed.: 1

22 doc.: IEEE /0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 22 Comments? Questions?


Download ppt "Doc.: IEEE 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 1 MAC beaconing sync comment resolution Date: 2011-01-20 Authors:"

Similar presentations


Ads by Google