1. doc.: IEEE 802.15-10-0655-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] 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 Comments: S7-490, S7-434, S7-489, S7-493, S7-504, S7-491, S7-391] [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-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 2 Proposed Resolution of D0 Comments S7-490, S7-434, S7-489, S7-493, S7- 504, S7-491 and S7-391 Hind Chebbo

3. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 3 D0 Comments Addressed S7-490Hind ChebboFujitsu S7-434Charles FarlowMedtronic S7-489Hind ChebboFujitsu S7-493Hind ChebboFujitsu S7-504Hind ChebboFujitsu S7-491Hind ChebboFujitsu S7-391Ichirou IDAFujitsu Assigned To reassign to Ranjeet

4. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 4 S7 - 490 same as S6 - 469 Page 112, sub clause 7.12..3 & 7.12.3.1, line 11 Comment: The frame formats of Ban enquiry frame and Ban enquiry response frame are not defined. or I believe they are defined under different names. Line 19: BAN descriptor pertaining to coexistence need to be defined ; it is not defined in coexistence enquiry response Line 4: BAN descriptor in B2 is not specified in B2 Proposed change: to replace: "BAN enquiry request" with "command-coexistence request" (Note: in table 11, coexistence mode field set to the value of 10 for Piconet Enquiry). "BAN enquiry response" with "command-Coexistence response" and use the reserved value of "11"of coexistence mode field for the piconet enquiry response. In figure 30, replace "allocation time/duty cycle" field to "allocation time/duty cycle/ BAN Descriptor" field. Note: the terminology used in sub-clause 7.12.3 should be customised to the definition in section 6.3.11.3- - 6.3.11.5 (b) Note:the command-coexistence response( piconet enquiry response)in figure 30 should have a field for BAN descriptor (see section 7.12.3 page 112 lines19- 21) Proposed Resolution: Same as S6 - 469

5. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 5 S7- 434 Page 92, sub clause 7.8, line 30-31 Comment: This subclause appears to assume those implementing the IEEE standard will be compliant with Listen Before Talk (LBT) and Least Interfered Channel (LIC) requirements as defined elsewhere (e.g., as in EN 301 839-1 V1.3.1). Proposed change : Specify how "a new channel" will be selected. An option is to reference clause 10 in EN 301 839-1 V1.3.1. Proposed Resolution: Accepted in principle. Page 92, line 31: After “required by” add “, and in compliance with, ”.

6. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 6 S7- 489 Page 107, sub clause 7.12, line 27 Comment: to clarify more the difference between "Static(S)", "Semi- dynamic(SD)", "Dynamic(D)"; perhaps through use cases Proposed change: Example of usage or interpretation could be: Static - (1) a single BAN in a home; (2) each hospital room has a single patient with a single BAN and a fixed bedside hub device. Semi Dynamic - ambulatory patients in an elder care facility (slow moving, low periodic data rates) Dynamic - ambulatory patients in a hospital (fast moving, large numbers of BANS, continuous data traffic from many sensors) The intent of adding these classifications was for guidance - to reflect the variety of application types as well as applicability of the different coexistence mechanisms Proposed resolution: Accepted in principle. (1) Replace lines 26-30, page 107, and lines 1-2, page 108 with a new sub clause placed at the end of 7.12. (2) The changes are incorporated in doc. # IEEE 802.15- 10-0656-00-0006 (S7-489, S7-450, S7-409, S7-448, S7-416, S7-449, S7-437, S7-436, S7-451, S7-418).

7. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 7 S7- 493 Page 112, sub clause 7.12..3, line 26 Comment: To state explicitly in which network mode of operation the coexistence mechanisms are applicable Proposed change: NA Proposed resolution: In page 111,suclause 7.12.3, line 16, add at the beginning of paragraph the following ” the coexistence mechanisms described in this subclause are applicable to the beacon enabled network.” –Rational: mechanisms involves features of the beacon enabled network such as beacon, B2, RAP,CAP etc.

8. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 8 S7- 504 Page 112, sub clause 7.12..3 & 7.12.3.1, lines 19-20 & 42-45 Comment: What is the difference between BAN descriptor pertaining to network coexistence in BAN Enquiry Response and BAN descriptor in B2? The former is not defined and the latter does not match quite well with definition in B2 Proposed change: NA Proposed Resolution: To be reassigned to Ranjeet / Ashutosh

9. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 9 S7- 491 Page 112, sub clause 7.12..3, line 11 Comment: When (what timing) the hubs which are not synchronized with each other send or receive both "BAN enquiry" and "Ban enquiry response"? CAP or RAP1 or RAP2? Proposed change: NA Proposed Resolution: To be reassigned to Ranjeet / Ashutosh

10. doc.: IEEE 802.15-10-0655-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 10 S7- 391 Page 74, sub clause 7.2.7.4, line 21 Comment: Why the following restriction applies for B-ACK? : "These frames should not be longer than the frame sent in the last block transmission." Proposed change: Explanation and usage example are required. Proposed resolution: Remove the sentence “These frames should not be longer than the frame sent in the last block transmission”. Reason being: (1) This restriction could cause frame sizes to become smaller and smaller, and even very small. (2) The maximum frame size is not that big in this standard anyway.