1. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 1 General frame format comment resolution overview Date: 2010-05-13 Authors:

2. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 2 Abstract Summary of the suggested G-Frame comment resolution There are 16 comments in G-Frame category –Place holders (CID 3001,3002,3003) –Clarification (CID3030, 3151, 3278, 3288, 3289) –Group address conversion (CID3024) –Header fields (CID3276, 3277) –Mesh ID (CID3153) –Action frame category (CID3193) –Multihop Action frame (CID3152, 3266, 3211)

3. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 3 Place holders (CID 3001, 3002, 3003) CID3001: –The definition of the management frames of such a complex concept as a WLAN mesh network contains very likely some flaws that will have an impact on the functionality and proper working of the WLAN mesh network. CID3002 and 3003 say the similar things.  Suggested resolution: –Counter: –Through the LB161 comment resolution process, management frame definition has been carefully reviewed.

4. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 4 Clarification (CID3030, 3151, 3278, 3288, 3289) Largely, these comments ask for the better wording or check for the validness of the descriptions. –CID3030: use of reserved field –CID3151: Subclause 7.5 (which is removed by 11n) –CID3278: BSSID and Address 3field convention –CID3288: Points out error for the Multihop Action frame subtype –CID3289: Address 4 for Multihop Action frame  Suggested resolutions: –Please look at the xls spreadsheet for the concrete resolutions.

5. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 5 Group address conversion (CID3024) 7.3.2.104 MCCAOP Setup Request element: –"... is transmitted in individually addressed frames to each of the intended responders or in a group addressed frame.“ A frame is either a broadcast or a unicast. If it is a broadcast, it might be possible to perform it by multiple unicasts. But this is not the right place to describe this. Furthermore, one of the important aspects of a broadcast is that it does not need to know all recipients.  Suggested resolution: –Delete the individually addressed frames... in 7.3.2.104 –Add the following text as the last paragraph in 11C.7.4.5.1 "A mesh STA may convert a group addressed management frame to individually addressed frames and transmit as individually addressed frame to each peer mesh STAs, if the frame is intended to be delivered to its peer mesh STAs only. The circumstances for choosing this method are outside the scope of the standard."

6. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 6 Header fields (CID3276, 3277) CID3276: –Adding the proposed mesh entry to the QoS Control field implies that the parsing of the QoS Control field has now become dependent on the MAC addresses earlier in the MAC header. I am not sure if this is a good idea. Also not because future amendments may add other MAC address specific parsing, based on this precedent. –Suggested resolution: Reject Use QoS Control field specific to mesh STAs, as defined currently. CID3277: –iven that the Mesh Control field is part of the frame body anyway, it might as well be preceded by an Ethertype that announces its presence. This way you don't have to announce the field through the QoS Control field. –Suggested resolution: Reject Mesh Control field is place before the LLC/SNAP header. QoS Control field is useful to signal the presence of Mesh Control field.

7. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 7 Mesh ID (CID3153) Mesh ID in a Probe Request frame: –It is not clear if Mesh ID element is always necessary in the probe request frame to discover mesh BSS. –Does mesh STA respond with Probe Response if the received Probe Request does not contain Mesh ID?  Suggested resolution: –Mesh STA responds with Probe Response only if the received Probe Request contains Mesh ID element. This helps in reducing unnecessay Probe Responses to the Probe Request from legacy STAs looking for AP or IBSS. Strawpoll: Do you think it is a reasonable resolution?  Y/N/A

8. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 8 Action frame category (CID3193) CID3193: –TGs tries to consume 6 category values. However, Mesh Link Metric category, MeshPath Selection category, and Mesh Interworking category only contains only small number of frames defined. It seems like a waste of category value. –Consolidate the action category as following: Mesh Action frames : contains Mesh Link Metric, Mesh Path Selection, Mesh Interworking, and Mesh Resource Coordination. Mesh Multihop Action frames: contains Mesh Proxy Forwarding. Self Protected frames: contains Self Protected. –Suggested resolution: Accept in principle, and reorganize the mesh action frames appropriately. –Strawpoll: Do you think it is a reasonable resolution?  Y/N/A

9. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 9 Multihop Action frame (CID3152, 3266, 3211) CID3152: –Instead of using a reserved subtype for the management frames, add a new category of management action frame for 4-address mesh multihop action frames. CID3266: –The reserved frame subtype should be used only when absolutely necessary. Instead of using a reserved subtype for the management frames, add a new type of "management action frame" for 4-address mesh multihop action frames. Change the "action" field of the currently defined in multiphop management frames (see 7.4b.2) to "sub-action". Change relevant text throughout the 11s spec. CID3211: –Multihop Action frame format is poorly described. Need to describe more detailed information.

10. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 10 Multihop Action frame (CID3152, 3266, 3211) We need to discuss what to do... Option 1: –Consume a subtype for Multihop Action as in D5.0.  Reject CID3152 and 3266 Option 2: –Define Multihop Action as one of the Action frame as suggested by CID3152 and 3266. –This requires a change in Mesh Control field definition, as Address 3 does not contain DA in Action frames. (Or change the Address 3 definition for Multihop Action) –Mesh Control field follows Category field, which is a bit confusing. Option 3: –Use other mean to signal “Multihop management frame” –One possible idea is to use FromDS or ToDS (preferably FromDS) bit to signal the 4-6 address extension for the management frame. Strawpoll: Which option do you prefer?  Op1/Op2/Op3/Other

11. doc.: IEEE 802.11-10/0537r0 Submission May 2010 Kazuyuki Sakoda, Sony CorporationSlide 11 Comments? Questions?