September 2010 doc IEEE 802 15 10 0674

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of TG 6 comments: S 6 -497 to S 6 -502] Date Submitted: [05 September, 2010] Source: [Rick Powell] Company [Zarlink] Address [15822 Bernardo Center Dr, Ste B, San Diego, CA, 92127] Voice: [+1 858 -675 -3485], FAX: [+1 858 -675 -3450], E-Mail: [rick. powell@zarlink. com] Re: [Proposed Resolution of D 0 Comments S 6 -497 to S 6 -502] Abstract: [Comment resolution for letter ballot 55 for S 6 -497 to S 6 -502] Purpose: [Propose Resolution of D 0 Comments S 6 -497 to S 6 -502] Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. Submission 1 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 Proposed Resolution of D 0 Comment S 6 -497 to S 6 -502 Comments relative to the setting and use of the “More Data” bit. Submission 2 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 D 0 Comment S 6 -497 • Page 23, Sub-clause 6. 2. 1. 1. 9, Line 5 • Comment: Does the behavior of the More bit have the same meaning in uplink data frames in CSMA, Uplink Allocation Intervals, Bilink allocation Intervals, Unscheduled Polling intervals, Delayed Polling intervals, Improvised Polling Intervals? Is the response by the Hub the same in all of these cases. Does the behavior of the More bit have the same meaning in acknowledgement frames from the Node to the Hub in response to downlink/posted frames in Downlink Allocation Intervals, Bilink allocation Intervals, Unscheduled Polling intervals, Delayed Polling intervals, Improvised Polling Intervals, CSMA allocation? Is the response by the Hub the same in all of these cases. • Proposed change: Confirm that there is no difference in behavior for the different access modes, or define the differences. Submission 3 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 • Analysis: There are differences in the use of the More Data bit in the various access modes in frames from the node to the hub. It is not clear how the hub “should” respond to the More Data bit being set in the Ack frame from the node in the different access modes. The function of the More Data bit is also not defined consistently in the various uplink allocations, particularly in regards to aborting/terminating the current allocation interval. The Proposed Resolution for S 6 -499 addresses this later case. For the former case, this is best handled in Section 7. • Proposed resolution: Define suggested behaviour of the hub in response the node setting the More Data bit to 1 in an I-Ack or B-Ack frame for the various downlink access modes, including scheduled downlink allocation, scheduled bilink (post) allocation, and unscheduled post allocation. Submission 4 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 D 0 Comment S 6 -498 • • Page 23, Sub-clause 6. 2. 1. 1. 9, Line 5 Comment: The behavior relative to the More bit during CSMA needs clarification. If the More bit is set in a CSMA Uplink access, how does the Hub respond when the I-Ack policy is set to I-Ack or B-Ack? Does the Hub respond with an Ack or an Ack+Poll? If with an Ack, can the Node send the next frame p. SIFS after the end of the Acknowledge frame transaction without another LBT? If with only an Ack, does this indicate that the Node should not send another frame? If with an Ack+Poll, can the Node send the next frame p. SIFS after the end of the Acknowledge frame transaction without another LBT? If the I-Ack field is set to N-Ack or L-Ack, can the Node send the next frame p. SIFS after the end of the current frame transaction without another LBT? Proposed Change: For CSMA access, the Hub should respond to the More bit being set the same as it does in other modes. When the I-Ack policy is set to IAck or B-Ack on an uplink data or management frame, the Hub may respond with either an Ack, or an Ack+Poll. If an Ack only, the Node may not send another Frame during the current access until a Poll is received. If an Ack+Poll, or a Poll is received, the Node may send another Frame p. SIFS after the end of the current frame transaction without another LBT. If the I-Ack Policy is set to NAck or L-Ack, the Node may send another frame p. SIFS after the end of the current frame transaction without another LBT. Note: The above Proposed Change makes an incorrect assumption that all types of uplink allocations require a poll to send another frame. This is not correct, so the Proposed Change is also incorrect. Submission 5 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 • Analysis: Currently, the CSMA allocation interval is defined as an uplink allocation, but it is not bounded by time or number of frames. The node does not have an efficient means for terminating a CSMA allocation interval, nor does the hub have an efficient means of responding to a node with management and/or data frames. Since the hub is allowed to send a unscheduled polls or posts at any time outside of scheduled access, this causes a potential collision situation and inefficient bandwidth utilization. This does not allow an efficient frame exchange. For non-superframe operation, for the connection process, for responding to allocation requests during CAP, and for applications that require bidirectional dialogs during CAP, an efficient frame exchange capability is desirable. A solution is to use the same abort rules for contented CSMA allocation as for a Type-II polled allocation. • Proposed Resolution: See proposed solution for S 7 -148. Submission 6 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 D 0 Comment S 6 -499 • Page 23, Sub-clause 6. 2. 1. 1. 9, Line 5 • Comment: Sect a) 2) Does this mean that for scheduled downlink or Post from the Hub, that if the node has uplink data, it can set the "More Data" bit during the ACK “frame”? If so, what are the options from the hub? Does it poll for immediate uplink transaction? Does it perform improvised scheduling? May a node send uplink data during a downlink allocation period? Does this mean that the Node must support Polling to send an uplink frame during a downlink allocation period? Proposed change: The Node may set the More bit in an Acknowledgement frame. Hub should respond to the More bit being set the same as it does in other modes. When the I-Ack policy is set to I-Ack or B-Ack on an uplink data or management frame, the Hub may respond with either an Ack, or an Ack+Poll. If the Hub sends an Ack only, the Node may not send another Frame during the current access until a Poll is received. If an Ack+Poll, or a Poll is received by the Node, the Node may send another Frame p. SIFS after the end of the current frame transaction, or if a delayed poll, receive the poll in the improvised scheduled slot. If the I-Ack Policy is set to N-Ack or L-Ack, the Node may send another frame p. SIFS after the end of the current frame transaction, providing adequate time remains in the allocation interval. • Submission 7 <Rick Powell>, <Zarlink>

<September 2010> • doc. : IEEE 802. 15 -10 -0674 -00 -0006 Analysis: This comment addresses the issue of how to control the flow of frames by the hub consistently between the different modes. It also suggests how to use allocation intervals efficiently, suggesting that Type-II allocation interval abort methods be used for all types of uplink allocations. However, Type-II abort methods may not be suitable for some uplink allocations. • Proposed resolution: Change Page 23, Line 4 from: 2) it is set to zero if the node has no pending frame transactions to initiate with the hub, or To: 2) it is set to zero if the node has no pending frame transactions to initiate with the hub. In this case, the allocation interval is terminated, and the hub may reclaim the remainder of the allocation interval for other purposes. Submission 8 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 D 0 Comment S 6 -500 • • Page 23, Sub-clause 6. 2. 1. 1. 9, Line 9 Comment: There is no restriction on the ACK policy if the More bit is set on a management or data frame from the Hub to the node. What would be the response if an ACK policy is set to I-Ack or B-Ack? In this case, the Node should reply with either the I-Ack or B-Ack, causing a collision. Stating that this bit being set indicates a Post p. SIFS after the end of the current frame transaction, negates the ability to use this bit to allow the Node to go to sleep after the last transmission, in the case where the allocation interval has not completed. A better use of this bit is to combine it with the Ack policy. If the More Bit is set, and an I-Ack or B-Ack is requested, then the Node will know that it must continue listening after it transmits the Ack. If the More bit is 0, then the Node can go to sleep after sending the Ack. Proposed change: Change the meaning of the More bit for management or data frames from the Hub to Node as follows: It is set to 1 if the hub is to send a post to the node p. SIFS after the end of the current frame transaction when the Ack policy is N-Ack or L-Ack, or to send a post to the node p. SIFS after the end of the Acknowledge frame transaction when the Ack policy is I-Ack or B-Ack. Submission 9 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 • Analysis: Although using the terminology of “frame transaction” applies to cases when a Acknowledgement is or is not requested, it would be clearer to state the requirement more explicitly. Also, the timing requirement is different depending on the requested Ack type. • Proposed resolution: Change Page 23, Line 5 from: 2) it is set to one if the hub is to send a post to the node p. SIFS after the end of the current frame transaction. To: 2) It is set to 1 if the hub is to send a post to the node p. MIFS after the end of the current frame transaction when the Ack policy is L -Ack, or a poll after the end of the current frame transaction when the Ack policy is N-Ack, or to send a post or a poll to the node p. SIFS after the end of the Acknowledge frame transaction when the Ack policy is I-Ack or B-Ack. Submission 10 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 D 0 Comment S 6 -501 • Page 23, Sub-clause 6. 2. 1. 1. 9, Line 9 • Comment: Sect b) 2) What is the setting when the Hub will be sending a Poll immediately following a Post? Wouldn't it set the More bit to a 1 in the Posted Frame to indicated that the Node will immediately receive another Frame to prevent the node from going to sleep. • Proposed change: In unicast management and data type frames sent by a hub to a node, the More bit is set to one if the hub is to send a post or a poll to the node p. MIFS after the end of the current frame when the ACK policy is N-Ack or L-Ack, or p. SIFS after the I -Ack or B-Ack frame from the Node to the Hub if the Ack Policy is set to I-Ack or B-Ack. • Proposed resolution: The proposed resolution to S 6 -500 resolves any issue with this comment. See proposed resolution for S 6 -500. Submission 11 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 D 0 Comment S 6 -502 • Page 23, Sub-clause 6. 2. 1. 1. 9, Line 12 • Comment: Sect c) 1) If this is a scheduled uplink access, what does the node do in the case where its allocation interval has not ended? Does this mean that the Hub will switch to receive mode waiting for a frame from the node? In scheduled uplink, what allows the node to send another frame after receiving an IAck or B-Ack from the Hub, if there is sufficient time for another frame in the current uplink allocation? Is setting the More bit to zero in the Ack form the Hub adequate, or does the Node need a Poll before sending another frame. If the More bit is set to zero in the Ack, does this mean that the node may not send another frame and may go to sleep? Has scheduled uplink behavior been defined in this document? • Proposed change: In I-Ack and B-Ack frames sent by a hub to a node, the More bit is set to zero if the hub is not to send a post or a poll to the node after the end of the current. In this case, the Node may not send another frame, and current access allocation is terminated, even if the allocation period has not expired. This is true for all access modes. Submission 12 <Rick Powell>, <Zarlink>

<September 2010> doc. : IEEE 802. 15 -10 -0674 -00 -0006 • Analysis: This proposal does not meet the needs of scheduled uplink allocations. In this case, the node needs to be able to send multiple uplink frames to the hub until the allocation interval has completed. It is not dependent on the More Data bit in the Ack frames from the Hub. However, there needs to be a means for the node to terminate the current allocation interval if it is no longer needed, and this point is addressed in the Proposed Resolution for S 6 -499. • Proposed resolution: Reject this comment. Submission 13 <Rick Powell>, <Zarlink>