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-497 to S6-502]
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-497 to S6-502]
Abstract: [Comment resolution for letter ballot 55 for S6-497 to S6-502]
Purpose: [Propose Resolution of D0 Comments S6-497 to S6-502]
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. Proposed Resolution of D0 Comment S6-497 to S6-502
<September 2010>
Proposed Resolution of D0 Comment S6-497 to S6-502
Comments relative to the setting and use of the “More Data” bit.
<Rick Powell>, <Zarlink>

3. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-497
Page 23, Sub-clause , 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.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

4. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
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 S6-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.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

5. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-498
Page 23, Sub-clause , 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 pSIFS 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 pSIFS 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 pSIFS 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 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 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 pSIFS after the end of the current frame transaction without another LBT. If the I-Ack Policy is set to N-Ack or L-Ack, the Node may send another frame pSIFS 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.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

6. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
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 S7-148.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

7. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-499
Page 23, Sub-clause , 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 pSIFS 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 pSIFS after the end of the current frame transaction, providing adequate time remains in the allocation interval.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

8. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
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.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

9. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-500
Page 23, Sub-clause , 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 pSIFS 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 pSIFS 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 pSIFS after the end of the Acknowledge frame transaction when the Ack policy is I-Ack or B-Ack.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

10. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
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 pSIFS 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 pMIFS 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 pSIFS after the end of the Acknowledge frame transaction when the Ack policy is I-Ack or B-Ack.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

11. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-501
Page 23, Sub-clause , 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 pMIFS after the end of the current frame when the ACK policy is N-Ack or L-Ack, or pSIFS 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 S6-500 resolves any issue with this comment. See proposed resolution for S6-500.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

12. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
D0 Comment S6-502
Page 23, Sub-clause , 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 I-Ack 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.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>

13. doc.: IEEE 802.15-<doc#1>
<September 2010>
doc.: IEEE <doc#1>
<September 2010>
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 S6-499.
Proposed resolution: Reject this comment.
<Rick Powell>, <Zarlink>
<Rick Powell>, <Zarlink>