September 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG6 Proposed MAC comment resolution] Date Submitted: [03 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 Comments: S7-243, S7-501, S7-492, S7-494, S7-496, S7-497, S7- 488, S7-498 ] [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. 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. Hind Chebbo, Fujitsu

September 2010 Proposed Resolution of D0 Comments: S7-243, S7-501, S7-492, S7-494, S7-496, S7-497, S7- 488, S7-498 Hind Chebbo Hind Chebbo, Fujitsu

D0 Comments Addressed Assigned to me S7 -243 Charles Farlow Medtronics September 2010 D0 Comments Addressed Assigned to me S7 -243 Charles Farlow Medtronics S7 – 501 Hind Chebbo Fujitsu S7 – 492 Hind Chebbo Fujitsu S7 – 494 Hind Chebbo Fujitsu S7 – 496 Hind Chebbo Fujitsu S7 – 497 Hind Chebbo Fujitsu S7 – 488 Hind Chebbo Fujitsu S7 – 498 Hind Chebbo Fujitsu Hind Chebbo, Fujitsu

S7 – 243 Page 94, subclause 7.8.2.1, lines 9-10 September 2010 S7 – 243 Page 94, subclause 7.8.2.1, lines 9-10 Comment: It is unclear how a switch to another channel is performed Proposed change: Specify if Listen Before Talk (LBT)/Least Interfered Channel (LIC) assessment will be performed and how.  An option is to reference clause 10 in EN 301 839-1 V1.3.1. Proposed resolution: Rejected.  This paragraph talks about the node, which does not select a channel based on LBT/LIC assessment but rather selects a channel to be on the same channel as is the hub.  So other than following the channel order list provided by the hub, the node's selecting a channel is an implementation issue. Hind Chebbo, Fujitsu

S7 - 501 Page 92, sub clause 7.7.5, line 21-22 September 2010 S7 - 501 Page 92, sub clause 7.7.5, line 21-22 Comment: corresponding fields removed Proposed change: remove the phrase: "or MSDU……" till the end of the phrase Proposed resolution: accepted; delete the phrase starting from “or MSDU…) Hind Chebbo, Fujitsu

S7 – 492 (1) Page 112, sub clause 7.12.3, line 24 September 2010 Page 112, sub clause 7.12.3, line 24 Comment: How should the hub detect no network activity? It does not receive any MAC frame from another hub? (passive scan?) Proposed change: NA Hind Chebbo, Fujitsu

S7 – 492 (2) September 2010 Proposed resolution: Accepted in principle. Delete the paragraph in lines 22-25 based on the comment and the following reasons: (1) How long a hub will do an active scan is much up to its own decision and hence is implementation specific (as is already indicated in the paragraph), and therefore is out of the scope of this spec. (2) The (run-on) sentence in lines 22-24 has too many ambiguities -- Is "active scan" an aggregate of "active channel scan(s)"? Is "when no enquiry response frame is received in mActiveScanDuration" duration" measured in a given channel or the overall active scan procedure (which involves scanning more than one channel)? Why shall the (overall) active scan terminate after a time out occurs in a single channel only (as the current wording appears to suggest)? (3) “Coordinator may select an unoccupied channel for network operation, at the termination of active scan.” May a hub select an unoccupied channel before an active scan? If yes, the statement has no teeth; if no, active scan would be mandatory. Hind Chebbo, Fujitsu

September 2010 S7 – 494 Page 115, sub clause 7.13.2, line 28 Comment: How the recipient in HARQ distinguishes new frame from retransmission with the setting of H0H1=10 since the retry bit in the MAC header is unchanged Proposed change: The recipient should ignore the retry bit during the HARQ process. When PHY header has H1H0=10 the MAC header should be used for the identification of retransmission based on the definition provided in clause 7.2.8 while ignoring the retry bit for the detection of duplicate transmission Proposed resolution: Accepted in principle.  Revise the HARQ description, especially the encoding of H0H1, in the UWB PHY spec to address the issue raised in the comment.  Hind Chebbo, Fujitsu

September 2010 S7 – 496 Page 109, sub clause 7.12.2, line 25 Comment: How to select a channel hopping sequence that is not used by its neighbor hubs Proposed change: NA Proposed resolution: Rejected. It is implementation specific and hence out of the scope of this spec. Hind Chebbo, Fujitsu

September 2010 S7 – 497 Page 86, subclause 7.6.2.1.1, line 3 Comment: in figure 66 an I-ACK is missing after the poll frame (see line 12&13) Proposed change: NA Proposed resolution: Accepted in principle.  (1) Delete the sentence in lines 12-13.  (2) Delete “I-Ack or” in the Ack Policy field of Table 18 for Poll and T-Poll frames.  (3) I-Ack and B-Ack are also sent to announce a future poll or post as indicated in Table 20, but their Ack Policy is N-Ack according to Table 18.  Thus, for consistency, Poll and T-Poll frames sent for the same purpose should have only N-Ack Ack policy Hind Chebbo, Fujitsu

S7 – 488 same as 387 Page 85, subclause 7.6.2, line 1 September 2010 S7 – 488 same as 387 Page 85, subclause 7.6.2, line 1 Comment: In Table 20, the following sentence require clarification: "A poll providing another poll but not a polled allocation may be considered a post Proposed change: One possible solution: A future poll may be considered a poll (with immediate polled allocation) or a post Proposed resolution: same as 387 Hind Chebbo, Fujitsu

S7 – 498 Page 86, sub clause 7.6.2.1.2, lines 16-17 September 2010 S7 – 498 Page 86, sub clause 7.6.2.1.2, lines 16-17 Comment: statement is true except for unconnected node Proposed change: to add "except for unconnected node Proposed resolution. Accepted in principles. To add in line 18 after “ the acknowledgement frame” the following “, except for unconnected node.” Proposed resolution: Accepted in principle: (1) After “polled allocation” in lines 16 and 21, add “granted to a connected node”. This also provides the precedent for “the node” that follows. (2) In line 23, after “return” add “of”. Hind Chebbo, Fujitsu