September, 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Resolution of D0 Comment S7-386, 387, 388, 392 and 393] Date Submitted: [6 September, 2010] Source: [Kaoru Yokoo1, Jin-Meng Ho2, Ichirou Ida1, Hind Munzer-Chebbo3] Company [1Fujitsu Laboratories Ltd., 2Texas Instruments, 3Fujitsu Laboratories Europe Limited] Address [1Kamikodanaka 4-chome, Nakahara-ku, Kawasaki 211-8588, Japan, 212500 TI Blvd, Dallas, TX, USA, 3Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K] E-Mail:[1{kaoru_yokoo,ida.ichirou}@jp.fujitsu.com, 2 jinmengho@ti.com, 3hind.chebbo@uk.fujitsu.com] Re: [Proposed Resolution of D0 Comment S7-386, 387, 388, 392 and 393] Abstract: [Proposed resolutions for S7-386, 387, 388, 392 and 393] Purpose: [To resolve comments came from 1st letter ballot of TG6] 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. Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

Proposed Resolution of D0 Comment S7-386 September, 2010 Proposed Resolution of D0 Comment S7-386 Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> September, 2010 D0 Comment S7-386 Place in document: subclause 7.13.2 ,line 35, page 115 Comment: Clarification is necessary: In line 35-36, it is prohibited for the sender to transmit another PPDU.When will it be allowed ? On the conditon described in line 37-39? Proposed Resolution:Clarfiy the logical connection between line35-36 and line 37-39 Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo <author>, <company>

Proposed Resolution Reject Editorial Withdrawn by the commenter. September, 2010 Proposed Resolution Reject Withdrawn by the commenter. Editorial Editorial change in line 37-39: “The sender shall ensure that its transmitted PPDUs containing either a MAC frame or the hybrid ARQ parity bits there of, …” Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

Proposed Resolution of D0 Comment S7-387 September, 2010 Proposed Resolution of D0 Comment S7-387 Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> September, 2010 D0 Comment S7-387 Place in the document: subclause 7.6.2, page 84 Comment: A hub may employ improvised polling and posting access to send polls or posts at previously announced times based on Table 20 and as described below to grant polled or posted allocations, either in beacon mode or non-beacon mode as also noted in 7.3, It is not clear the difference between unscheduled access and improvised access, because both of them use (immediate) polls or (immediate) posts on Table 20. The purpose of this comment note is to explicitly clarify the definition of Improvised access. Proposed Resolution: Possible Specification Change clause 7.6.2, page 84 : A hub may employ improvised polling and posting access to send polls or posts at previously announced times with future polls or future posts based on Table 20 and as described below to grant polled or posted allocations, either in beacon mode or non-beacon mode as also noted in 7.3, Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo <author>, <company>

Proposed resolution Accepted in Principle September, 2010 Proposed resolution Accepted in Principle Add more explanation as shown in the supplement document This makes little impact on the current document structure. Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

Alternative Resolution September, 2010 Alternative Resolution Accepted in Principle Currently unscheduled and improvised access is not exclusive each other. Thus, two subclauses are united as shown in the supplement document. Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

Proposed Resolution of D0 Comment S7-388 September, 2010 Proposed Resolution of D0 Comment S7-388 Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> September, 2010 D0 Comment S7-388 Place in Document: page 89, 7.7.1, line 20 , Editorial Comment: Not relevant anymore Proposed Resolution: to delete the phrase: or MSDU……till the end of the phrase Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo <author>, <company>

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> September, 2010 Proposed Resolution Accept Editorial Use correct name of parameters and delete obsolete parameters as below In these IEs, the Minimum Length and Allocation Length fields, when present, shall have nonzero values. Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo <author>, <company>

Proposed Resolution of D0 Comment S7-392 September, 2010 Proposed Resolution of D0 Comment S7-392 Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> September, 2010 D0 Comment S7-392 Place in Document: Page 85, 7.6.2 Line 1 Comment: There are two types of poll, one is immediate poll another is future poll. Unlike immediate poll, future poll does not have any information of polled allocation for the addressed node. The purpose of this comment note is to explicitly clarify the definition of immediate poll and future poll. Proposed Resolution: Additional explanation in Table 20 are as follows, -Immediate poll is to grant an immediate polled allocation to the node -Future poll is to inform the node of an intended future poll(immediate or future) or post. Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo <author>, <company>

Proposed Resolution Reject Already covered by the resolution of S7-387 September, 2010 Proposed Resolution Reject Already covered by the resolution of S7-387 Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

Proposed Resolution of D0 Comment S7-393 September, 2010 Proposed Resolution of D0 Comment S7-393 Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> September, 2010 D0 Comment S7-393 Place in Document: Page 109, 7.12.1 Line 8 Comment : How do nodes identify RAP1 and RAP2 length at the very beginning superframe (BP 0) when beacon hopping is enabled? According to the description,RAP1 and RAP2 length field in the beacon of BPn refers BPn+1. What happened in the beginning ? (n+1 <- n<- n-1 <- … -<- 2 <- 1 <- 0 <-1 ?? ) Proposed Resolution : If nodes do not need to know the RAP1 and RAP2 length at BP0 because it's a transient period, specify so. Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo <author>, <company>

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> September, 2010 Proposed Resolution Accepted in principle. Replace the last sentence in lines 8-9, page 109, with the following: “The RAP1 and RAP2 related fields contained in the beacon of the current beacon period now refer to the EAP1, RAP1, EAP2, and RAP2 in the next beacon period. A node does not know nor use these access phases in the beacon period in which it received its first beacon indicating beacon shifting is enabled, but it may use Type I and Type II access phases through polls and posts” Kaoru Yokoo, Jin-Meng Ho, Ichirou Ida, Hind Munzer-Chebbo <author>, <company>