1. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 1 NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate fields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG6 Proposed MAC Comment Resolution Proposed Resolution of D0 Comment S6- 420, S6-468, S6-494, S6-393, S6-469, S6-462, S6-6, S6-461] Date Submitted: [02 September, 2010] Source: [Hind Chebbo] Company [Fujitsu] Address [Hayes Park Central, Hayes, UB4 8FE, Middlesex, UK] Voice:[+44 (0) 20 8606 4809], FAX: [+44 (0) 20 8606 4539], E-Mail:[Hind.Chebbo@uk.fujitsu.com] Re: [Proposed Resolution of D0 Comment S6-420, S6-468, S6-494, S6-393, S6-469, S6-462, S6-6, S6- 461] [If this is a response to a Call for Contributions, cite the name and date of the Call for Contributions to which this document responds, as well as the relevant item number in the Call for Contributions.] [Note: Contributions that are not responsive to this section of the template, and contributions which do not address the topic under which they are submitted, may be refused or consigned to the “General Contributions” area.] Abstract:[Description of document contents.] Purpose:[Description of what the author wants P802.15 to do with the information in the document.] Notice:This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release:The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 2 Proposed Resolution of D0 Comments: S6- 420, S6-468, S6-494, S6-393, S6-469, S6- 462, S6-6, S6-461 Hind Chebbo

3. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 3 D0 Comments Addressed S6-420Kuor-Hsin Chang Elster Solutions S6-468Hind Chebbo Fujitsu S6-494Didier Sagan Zarlink Semiconductor S6-393David Tracey WiSAR Lab S6-469Hind Chebbo Fujitsu S6-462Hind Chebbo Fujitsu S6-6 Sverre Brubæk Texas Instruments S6-461Hind Chebbo Fujitsu Assigned

4. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 4 D0 Comment S6 – 420 Page 51-52, sub clause 6.4 Comment: frame defined in clause 6.4.7. Proposed change: Consolidate these two frames. Proposed resolution:Accepted in principle. To remove Wakeup frame and all references to it, and the subclauses 7.8.2.1.1, 7.8.2.1.2, and 7.8.2.1.4. Frame payload

5. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 5 D0 Comment S6 - 468 Page 58, sub clause 6.7,line 1 Comment: to introduce New set of optional Assignment IEs (for uplink/Downlink and or Bilink) for relaying purposes to distinguish between the assignment of relaying node and the relayed node in the connection assignment of the relaying node Proposed change: to introduce New set of optional Assignment IEs (for uplink/Downlink and or Bilink) Proposed resolution: Accepted in principle. The comment is adressed in doc IEEE P802.15-10-0544-01-0006. In Page 42, to modify figure 25 to include optional sd-hop uplink assignment, sd- hop downlink assignment, sd hop Bilink assignment respectively after the existing optional uplink assignment, downlink assignment, Bilink assignment respectively

6. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 6 D0 Comment S6 - 494 Page 21, sub clause 6.2.1.1.5, line 22 Comment: The use of the Relay bit is not clearly defined. It is set in the Header the encapsulated Frame as well as in the Header of the "encapsulating" frame. When the "Relayed" node sends a Frame to the "Relaying" node, does the "Relayed" node set the Relay bit? This is a non-encapsulated Frame, destined for the Hub. When the "Relaying" node receives this frame and encapsulates it for transmission to the Hub, does it set the Relay bit in the outer Header? When the Hub transmits an encapsulated frame to a "Relayed" node, does it set the Relay bit in the encapsulated Header? Does it set the Relay bit in the Outer Header? When the "Relaying" node de-encapsulated the Frame received from the Hub and destined for the "Relayed" node, does it set the relay bit in the Header? Proposed change: The Relay bit can be used to indicate that an encapsulated Frame is contained within the current transacted frame. So, the definition of this bit should be: The Relay field is set to 1 in frames sent to or from a relaying node in a two-hop extended star network. It shall only be set in frames which contain an encapsulated frame which is being relayed. It shall not be set in the header of the encapsulated frame, but only in the outer header of a frame that contains an encapsulated relayed frame. It is reserved in all other frames. Proposed resolution: Accepted in principle. The comment is addressed in doc IEEE P802.15-10-0544-01-0006.

7. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 7 D0 Comment S6 - 393 Page 21, sub-clause 6.2.1.1.5, line 18-19 Comment: In relay mode – what are the correct settings for recipient and sender ID's - is the recipient ID that of hub and sender id that of original leaf node sender? Proposed change: Clarify use of node id's in relay mode. “From leaf to relay node and relay to hub, the sender id is the leaf node id and the recipient id is the hub id.” or is it “From leaf to relay node, the sender id is the leaf node id and the recipient id is the relay id. From relay to hub, the sender id is the leaf node id and the recipient id is updated to that of the hub id” Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-01-0006, see sub clause 7.9.1

8. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 8 D0 Comment S6 - 469 Same as S7- 490 Page 46-47, sub-clause 6.3.1.1.3 & 6.3.1.1.4.3, line 20 of page 46 & line 18 of page 47 Comment: There is no definition for Piconet response. Two sugestions for its introduction: a) to use value 5 of table 9 for Piconet Response OR b) to use value 11 of table 11. If we chose to select case a) I suggest to remove Piconet enquiri from table 11 to table 9 and assign it a value of 4 Proposed change: Two suggestions for its introduction: a) to use value 5 of table 9 for Piconet Response OR b) to use value 11 of table 11. If we chose to select case a) I suggest to remove Piconet enquiry from table 11 to table 9 and assign it a value of 4 Proposed resolution: Rejected. No such functional behaviour of "piconet response" is described in the corresponding functional description subclauses, so instead "piconet response" and all references to it should be removed.

9. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 9 D0 Comment S6 - 462 Page 48, sub-clause 6.3.1.1.5 (b), line 7 Comment: BAN Descriptor which is required for coexistence mechanisms is missing from figure 30 and need to be defined Proposed change: In figure 30 to replace the field "Allocation Time/Duty Cycle" with "Allocation Time/Duty Cycle/BAN Descriptor" but still BAN descriptor need to be defined Proposed resolution: Rejected. Remove "BAN Descriptor" instead, as its functionality is not described, even though it is mentioned a few times in the functional description subclauses

10. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 10 D0 Comment S6 - 6 Same as S6-420 Page 22, subclause 6.2.1.1.8, line 15 Comment: The Wakeup frame provides no more functionality and effectiveness than the Poll frame, as explained in detail in some related comments. Proposed change: Remove the row of "Wakeup" frame from Table 3, subclause 6.4.7 and subclause 7.8.2.1.1 (which should have never appeared). Accordingly, change "1011" to "0111" in the preceding row (for reserved frame subtype values of control type frames). Proposed resolution: Same as S6-420

11. doc.: IEEE 802.15 -10-0654-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 11 D0 Comment S6 - 461 Same as S7-490 and S6-469 Page 47, sub-clause 6.3.11.4.3 Comment: table 11- the reserved field should be replaced with Piconet Enquiry Response Proposed change: to use the field value "11" to indicate "Piconet Enquiry Response" frame Proposed resolution: Same as S7-490 and S6-469