Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of TG6 comments: S7-148] 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 D0 Comments S7-148] Abstract: [Comment resolution for letter ballot 55 for S7-148] Purpose: [Propose Resolution of D0 Comment S7-148] 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. <Rick Powell>, <Zarlink>

2. Proposed Resolution of D0 Comment S7-148 Comments relative to CSMA Contention Access. <Rick Powell>, <Zarlink>

3. D0 Comment S7-148 • Page 82, Sub-clause 7.5.1.2, Line 3 • Comment: It is not clear how the hub responds with management frames during a CSMA allocation. The protocol for frame exchange needs to be more clearly defined to specify how the Hub sends frames to the node during contention access. • Proposed Change: CSMA allocation periods behave similar to Unscheduled Poll, except that the exchange is initiated by the Node using the LBT mechanism and sending a frame to the Hub. Once the exchange has begun, the Hub controls the exchange by the use of Ack+Poll and Ack+More bit. If the Hub responds to an uplink frame with an Ack+Poll, then the Node has permission to send another Frame. If the Hub responds with an Ack and with the More bit set, then the Ack will be immediately followed by a Post from the Hub. When the Node Acks, or sends a Data/Management Frame, it may set the More bit to indicate that it has more data to send. The Hub may respond to a Data/Management Frame with an Ack, or an Ack+Poll. If the hub responds with an Ack+Poll, the Node may immediately send another frame. If the Hub responds with an Ack Only, then the Node shall listen for a Post from the Hub. When the node sends an Ack, it may set the More bit to indicate that it has more data. In this case, the Hub may either send a Poll to allow the node to transmit the frame, or it may Post a frame to the Node, or it may do nothing. • 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>

4. 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 for 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. This works well for nodes that only need to send one frame per allocation, and for nodes that support polling. For nodes that need to send more than one frame without supporting polling, then multiple CSMA allocations would be required. The alternative solution is to use a Type-I type abort mechanism. <Rick Powell>, <Zarlink>

5. Proposed Resolution: Change from: 7.5.1.3 Using a contended allocation To resume its transmission following a received acknowledgment frame, the node may transmit a new 7 frame or retransmit an old frame, with an UP not lower than the UP used to obtain the current contended 8 allocation, pSIFS after the end of the acknowledgment frame. The node shall end its transmission in the 9 allocation such that the last transmission in the allocation completes at least the nominal guardtime GTn = 10 mGT_Nominal earlier than the end of the allocation or of the current EAP, RAP, or CAP, whichever is 11 earlier. To: To resume its transmission following a received acknowledgment frame, the node may transmit a new 7 frame or retransmit an old frame, with an UP not lower than the UP used to obtain the current contended 8 allocation, pSIFS after the end of the acknowledgment frame. The node shall end its transmission in the 9 allocation such that the last transmission in the allocation completes at least the nominal guardtime GTn = 10 mGT_Nominal earlier than the end of the allocation or of the current EAP, RAP, or CAP, whichever is 11 earlier. 7.5.1.4 Aborting a contended allocation A node may abort the contended allocation by requesting an immediate or block acknowledgment. Upon receiving a data or management frame from the node requesting an I-Ack or B-Ack, the hub may send an I-Ack+Poll, B-Ack+Poll, I-Ack, or B-Ack. I-Ack+Poll or B-Ack+Poll should only be sent if the node sets the More Data to 1. If the hub sends an I-Ack or B-Ack, it may post a management or data frame pMIFS after the I-Ack or B-Ack frame, providing it sets the More Data bit to 1 in the I-Ack or B-Ack frame. If the hub sends an I-Ack or B-Ack frame with the More Data bit to 0, then the allocation is aborted. A node shall treat a contended allocation to have been aborted after failing to receive the expected acknowledgment frame in the allocation. Change from: 7.5.1.4 Aborting a contended allocation A node shall treat a contended allocation to have been aborted after failing to receive the expected acknowledgment frame in the allocation. A node may start a new contended allocation procedure as specified in 7.5.1 to obtain another contended allocation. To: A node may abort the contended allocation by requesting an immediate or block acknowledgment. Upon receiving a data or management frame from the node requesting an I-Ack or B-Ack, the hub may send an I-Ack+Poll, B-Ack+Poll, I-Ack, or B-Ack. I-Ack+Poll or B-Ack+Poll should only be sent if the node sets the More Data to 1. If the hub sends an I-Ack or B-Ack, it may post a management or data frame pMIFS after the I-Ack or B-Ack frame, providing it sets the More Data bit to 1 in the I-Ack or B-Ack frame. If the hub sends an I-Ack or B-Ack frame with the More Data bit to 0, then the allocation is aborted. A node shall treat a contended allocation to have been aborted after failing to receive the expected acknowledgment frame in the allocation. Change from: 7.5.1.5 Ending a contended allocation A node may at any time end a contended allocation by not following with another frame transmission in the allocation. To: A node may at any time end a contended allocation by sending a data or management frame with an I-Ack or B-Ack request, and setting the More Data bit to 0, and not responding to any subsequent Poll or Post from the hub. It may also end a contended allocation by sending a data or management frame with an N-Ack request, and setting the More Data bit to 0, and not responding to any subsequent Poll or Post from the hub. <Rick Powell>, <Zarlink>

6. Proposed Resolution: Change “7.5.1.3Using a contended allocation” from: To resume its transmission following a received acknowledgment frame, the node may transmit a new frame or retransmit an old frame, with an UP not lower than the UP used to obtain the current contended allocation, pSIFS after the end of the acknowledgment frame. The node shall end its transmission in the allocation such that the last transmission in the allocation completes at least the nominal guardtime GTn = mGT_Nominal earlier than the end of the allocation or of the current EAP, RAP, or CAP, whichever is earlier. To: To resume its transmission in the contention access phase following the transmission of a data or management frame requesting and I-Ack or B-Ack response, the node shall wait for a Poll, T-Poll, I-Ack+Poll or B-Ack+Poll, or it shall perform another instance of CSMA/CA. Change ”7.5.1.4 Aborting a contended allocation” from: A node shall treat a contended allocation to have been aborted after failing to receive the expected acknowledgment frame in the allocation. A node may start a new contended allocation procedure as specified in 7.5.1 to obtain another contended allocation. To: A node may abort the contended allocation by requesting an immediate or block acknowledgment. Upon receiving a data or management frame from the node requesting an I-Ack or B-Ack, the hub may send an I-Ack+Poll, B-Ack+Poll, I-Ack, or B-Ack. I-Ack+Poll or B-Ack+Poll should only be sent if the node sets the More Data to 1. If the hub sends an I-Ack or B-Ack, it may post a management or data frame pMIFS after the I-Ack or B-Ack frame, providing it sets the More Data bit to 1 in the I-Ack or B-Ack frame. If the hub sends an I-Ack or B-Ack frame with the More Data bit to 0, then the allocation is aborted. A node shall treat a contended allocation to have been aborted after the expected completion time of the expected acknowledgment frame in the allocation, regardless of whether or not it is received by the node.. Change ”7.5.1.5 Ending a contended allocation” from: A node may at any time end a contended allocation by not following with another frame transmission in the allocation. To: A node may at any time end a contended allocation by sending a data or management frame with an I-Ack or B-Ack request, and setting the More Data bit to 0, and not responding to any subsequent Poll or Post from the hub. It may also end a contended allocation by sending a data or management frame with an N-Ack request, and setting the More Data bit to 0, and not responding to any subsequent Poll or Post from the hub. <Rick Powell>, <Zarlink>

7. Alternate Resolution: Instead of using Type-II polling technique for aborting the allocation, an alternative is to use Type-I type abort. In this case, the node may transmit multiple data/management frame using I-Ack or B-Ack without requiring a Poll to send additional frames. Change from: 7.5.1.4 Aborting a contended allocation A node shall treat a contended allocation to have been aborted after failing to receive the expected acknowledgment frame in the allocation. A node may start a new contended allocation procedure as specified in 7.5.1 to obtain another contended allocation. To: 7.5.1.4 Aborting a contended allocation A node may relinquish the remaining allocation interval of a polled allocation by setting the more data bit to 0 in the frame being transmitted and then by transmitting no more frames in the interval, even in the case that a requested I-Ack or B-Ack is not received. Upon receiving a frame from the node with the more data bit set to 0, the hub may send an I-Ack or B-Ack if requested. If the hub sends an I-Ack or B-Ack, it may post a management or data frame pMIFS after the I-Ack or B-Ack frame, providing it sets the More Data bit to 1 in the I-Ack or B-Ack frame. If the hub sends an I-Ack or B-Ack frame with the More Data bit to 0, then the aborted of allocation is complete. A node shall treat a contended allocation to have been aborted after the expected completion time of the expected acknowledgment frame in the allocation, regardless of whether or not it is received by the node. Change from: 7.5.1.5 Ending a contended allocation A node may at any time end a contended allocation by not following with another frame transmission in the allocation. To: A node may at any time end a contended allocation by sending a data or management frame with the More Data bit set to 0, and not responding to any subsequent Post from the hub. <Rick Powell>, <Zarlink>