1. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Resolution of TG6 comments: S6-504, S6-510, S6-511, S6-512, S6-514, S6-515,
S6-516, S6-517, S6-518]
Date Submitted: [05 September, 2010]
Source: [Rick Powell] Company [Zarlink]
Address [15822 Bernardo Center Dr, Ste B, San Diego, CA, 92127]
Voice:[ ], FAX: [ ],
Re: [Proposed Resolution of D0 Comments S6-504, S6-510, S6-511, S6-512, S6-514, S6-515, S6-516,
S6-517, S6-518]
Abstract: [Comment resolution for letter ballot 55 for S6-504, S6-510, S6-511, S6-512, S6-514, S6-515, S6-516, S6-517, S6-518]
Purpose: [Propose Resolution of D0 Comment S6-504, S6-510, S6-511, S6-512, S6-514, S6-515, S6-516, S6-517, S6-518]
Notice: This document has been prepared to assist the IEEE P 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 P
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

2. <September 2010>
Proposed Resolution of D0 Comment S6-504, S6-510, S6-511, S6-512, S6-514, S6-515, S6-516, S6-517, S6-518
<Rick Powell>, <Zarlink>

3. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-504
Page 44, Sub-clause 6.3.8, Line 22
Comment: It is stated that the Multinode Connection Assignment is made with a broadcast (multicast) frame. When do nodes listen for broadcast or multicast frames? This could be useful for quickly changing the superframe structure, but there needs to be a well define time when nodes are listening.
Proposed Change: Add a period, immediately after the Beacon, when nodes are required to listen for broadcast/multicast frames when beacon mode is enabled.
Analysis:
It appears that this is not used for Group Allocation Assignments, but is intended to provide Allocation Assignments to multiple individual nodes with one frame. Currently, the only time this appears practical is during the initial configuration on the network, when multiple nodes are in the connection process and are waiting (listening) for their respective connection assignments. In this case, the hub may send connection assignments to multiple nodes with a single frame.
This frame does not seem useful for a general reassignment of allocation assignments, since there is no other time that all the nodes are listening for a multicast frame from the hub.
Proposed Resolution:
No change is recommended, but the usefulness of the Multinode Connection Assignment should be discussed, as well as its possible use for a fast change to the Allocation Assignment for multiple nodes.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

4. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-510
Page 51 Sub-clause , Line 2
Comment: This statement does not adequately specify the timing requirement. There needs to be more accuracy defined by referencing the offset to a specific symbol/bit location in the frame. How is the beginning transmission defined relative to the beginning of the slot?
Proposed Change: There is no a simple solution to this requirement. It will involve interaction between the PHY and the MAC, most likely with some timing information supplied to the MAC by the PHY on the receiver side. There also needs to be a tight link between the MAC and the PHY on the sender side so that the encoded value matches the delay from the start of the current slot. An accuracy must be defined such that guard times are not violated.
Proposed Resolution:
Add the following to Sub-clause :
This offset is referenced from the exact beginning of the slot period to the beginning of the first symbol in air relative to RF energy from the PHY.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

5. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-511
Page 54 Sub-clause 6.6.1, Line 2
Comment: What is the indication that a node supports unscheduled polling?
Proposed Change: Clarify.
Proposed Resolution:
The Type-I and & Type-II Polling capability fields can be used to indicate that a node supports unscheduled poling. Make for following changes:
Type-I Polling Access
The Type-I Polling Access field is set to one if the sender supports unscheduled Type-I polled allocations, and if the “schedule access” field bit is set to one, also supports scheduled Type-I polled allocations, or is set to zero otherwise.
Type-II Polling Access
The Type-II Polling Access field is set to one if the sender supports unscheduled Type-II polled allocations, and if the “schedule access” field bit is set to one, also supports scheduled Type-II polled allocations, or is set to zero otherwise.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

6. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-512
Page 55 Sub-clause , Line 11
Comment: Must the Type-I Polling Access bit be set in the MAC capability field for a Bilink Request IE to be included in the Connection Request Frame?
Proposed Change: Clarify.
Proposed Resolution:
The Type-I and/or Type-II Polling capability fields must be set to one for the node to request, or to be granted, a Bilink allocation.
Add the following to “6.7.4 Bilink Request IE”
The Type-I and/or Type-II Polling fields shall be set to one in the MAC Capability of the node if the node requests a Scheduled Bilink allocation.
Add the following to “6.7.9 Bilink Assignment IE”
The Type-I and/or Type-II Polling fields shall be set to one in the MAC Capability of the node if the node receives a Scheduled Bilink allocation.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

7. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-514
Page 55 Sub-clause , Line 14
Comment: Must the Type-II Polling Access bit be set in the MAC capability field for a Delayed Bilink Request IE to be included in the Connection Request Frame?
Proposed Change: Clarify.
Proposed Resolution:
The Type-II Polling capability fields must be set to one for the node to request, or to be granted, a Delayed Bilink allocation.
Add the following to “6.7.5 Delayed Bilink Request IE”
The Type-II Polling fields shall be set to one in the MAC Capability of the node if the node to requests a Delayed Bilink Allocation.
Add the following to “ Delayed Uplink Assignment IE”
The Type-II Polling fields shall be set to one in the MAC Capability of the node if the node to receives a Delayed Bilink Allocation.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

8. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-515
Page 55 Sub-clause , Line 17
Comment: Why is the Schedule Access Capability bit required. Is it not sufficient for a node to send a Scheduled type allocation request IE to indicate that it supports Scheduled access? Is there any time that a node would receive scheduled access without requesting it in an IE?
Proposed Change: Justify why this bit is required or removed it.
Proposed Resolution:
Remove the bit, or keep it. Needs discussion.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

9. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-516
Page 55 Sub-clause , Line 21
Comment: Why is the Delayed-Polling Access Capability bit required. Is it not sufficient for a node to send a Delayed Bilink allocation request IE to indicate that it supports Delayed-Polling access? Is there any time that a node would receive Delayed-Polling access without requesting it in an IE? Why is this defined as Delayed-Polling as opposed to Delayed-Bilink?
Proposed Change: Justify why this bit is required or removed it.
Proposed Resolution:
Remove the bit, or keep it. Needs discussion.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

10. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-517
Page 55 Sub-clause , Line 21
Comment: Why is this defined as Delayed-Polling as opposed to Delayed-Bilink? What is the difference? Hasn't Delayed-Polling been replaced with Delayed-Bilink?
Proposed Change: Clarify
Analysis:
Delayed-Polling Access occurs during a Delayed-Bilink Allocation and within a Delayed-Bilink Allocation Interval. Presumably, Delayed- “Posting” could also occur within a Delayed-Bilink Allocation, although it is not defined. Presumably, the ability to support Delayed-Polling also implies the ability to support Delayed-Posting.
Proposed Resolution:
Change references of “Delayed-Polling” to “Delayed-Bilink”, with the definition of Delayed-Bilink that it includes both Delayed-Polling and Delayed-Posting.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

11. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-518
Page 60 Sub-clause , Line 4
Comment: The term "Gap" is not clearly defined.
Proposed Change: Define "Gap" as follows: When the Wakeup Period field bit is '0', Gap is equal to the number of slots between the last slot of the allocation period and first slot the next allocation period for the same node in the same superframe, such that if the next allocation period starts immediately after the current allocation period, the Gap = 0. When the Wakeup Period field bit is '1', Gap is equal to the number of superframes between the current allocation period and the next allocation period for the same node, such that if allocations for the node occur in every superframe then the Gap = 0.
Proposed Resolution:
Add the following to “ Maximum Gap” :
When the Wakeup Period field bit is '0', Gap is equal to the number of slots between the last slot of the allocation period and first slot the next allocation period for the same node in the same superframe, such that if the next allocation period starts immediately after the current allocation period, the Gap = 0. When the Wakeup Period field bit is '1', Gap is equal to the number of superframes between the current allocation period and the next allocation period for the same node, such that if allocations for the node occur in every superframe, then the Gap = 0.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>