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

2. doc.: IEEE 802.11-11/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 802.11-11/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 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 4 Overview –BT element extension: 1137 1254 1355 –BT element naming: 1143 1148 1150 1151 1152 –BT element procedure: 1177 1204 1312 –Clock drift: 1259 –Delayed beacon transmission: 1237 –doc structure: 1279 1281 1282 –Extensible framework: 1268 –MIB: 1234 1270 –MLME: 1114 1118 1262 1263 1325 –Report Status subfield: 1213 –Status code: 1190 –Sync protocol: 1274 1278 –Omission: 1242 1138 –Wording: Rest of the comments

5. doc.: IEEE 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 5 Comments relatively easy to resolve Wording, omission, MIB, delayed beacon transmission: –1083 1115 1116 1117 1119 1121 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1134 1138 1139 1140 1141 1142 1144 1145 1146 1147 1149 1153 1154 1155 1157 1160 1161 1162 1164 1165 1167 1168 1169 1175 1178 1182 1183 1184 1185 1186 1187 1188 1189 1193 1194 1198 1199 1202 1203 1205 1206 1207 1211 1212 1214 1216 1217 1218 1219 1220 1221 1222 1227 1229 1233 1235 1236 1237 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1250 1251 1252 1253 1257 1258 1260 1261 1264 1265 1267 1269 1270 1271 1275 1276 –Ask to provide a better text Suggested resolutions are available in 11-11/99r0 and 11- 11-100r0.

6. doc.: IEEE 802.11-11/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: –1120 1122 1133 1135 1136 1158 1159 1163 1166 1170 1171 1172 1173 1174 1176 1181 1191 1195 1201 1208 1209 1210 1215 1238 1277 1280 1156 1179 1180 1255 1256 1231 1197 1225 1226 1228 1230 1200 1313 MLME: –1114 1118 1262 1263 1325 Extensible framework: –1268 Status code: –1190

7. doc.: IEEE 802.11-11/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 802.11-11/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 802.11-11/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.12.2.2.3, 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.12.2.2.3. Clock drift compensation should be done in MBCA and in MCCA and in power management independently? Clock drift compensation is useful.

10. doc.: IEEE 802.11-11/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 16.777 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 802.11-11/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 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 12 doc structure CID1279 –move 11C.12.1 to 11.1.1.3 and change title into "TSF for an MBSS –- remove last paragraph (lines 49-50) because they are implicit if this clause is in 11.1. CID1282 –An uncited definition in IEEE 802.11 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 802.11-11/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 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 14 BT element procedure In 11C.12.4.2.4, 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.12.4.2.3, 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 802.11-11/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 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 16 Further discussion

17. doc.: IEEE 802.11-11/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 802.11-11/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 802.11-11/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 802.11-11/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 802.11-11/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 802.11-11/0101r4 Submission January 2011 Kazuyuki Sakoda, Sony CorporationSlide 22 Comments? Questions?