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

Proposed Resolution of D0 Comment S6-503 <September 2010> Proposed Resolution of D0 Comment S6-503 Comments relative to Allocation Assignment Frame transmission. <Rick Powell>, <Zarlink>

doc.: IEEE 802.15-<doc#1> <September 2010> doc.: IEEE 802.15-<doc#1> <September 2010> D0 Comment S6-503 Page 42, Sub-clause 6.3.7, Line 1 Comment: After the Connection Request Frame, is the Connection Assignment frame transmitted by the Hub expected pSIFS later? Or, does the Hub perform an I-Ack per Ack policy and then "Post" the Connection Assignment Frame pMIFS after the Ack Frame? What happens when the Hub does not have enough time to process the request in time to send it immediately after the Request or Ack? In that case, how is the Assignment Frame sent, since this occurs during a contention period and the Hub shall not initiate a Post?. 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. <Rick Powell>, <Zarlink> <Rick Powell>, <Zarlink>

doc.: IEEE 802.15-<doc#1> <September 2010> doc.: IEEE 802.15-<doc#1> <September 2010> Analysis: Allocation Request frames may be sent by the node to the hub during RAP or CAP, using either CSMA or Slotted ALOHA. In either case, the node should request an I-Ack response. The hub should process the request and respond with an Allocation Assignment frame. Currently, there is no recommendation regarding how or when the Allocation Assignment frame is sent to the node from contention access Allocation Request. This ambiguity needs to be addressed to minimize power and to ensure interoperability. There are at least 4 possible ways the hub can send the Allocation Assignment frame. If the hub has sufficient time and processing bandwidth, it may return the Allocation Assignment frame immediately. This is done by the hub setting the More Data bit to 1 in the Ack frame to the Allocation Request frame, and sending the Allocation Assignment frame pMIFS after the Ack Frame. The Proposed Resolution to S7-148 allows this behavior in Contention Access. This solution provides the lowest power consumption for nodes which do not have a scheduled allocation. Note: If an I-Ack Frame is requested, then the Hub has a minimum of 2 milliseconds for prepare the Allocation Assignment payload before the Allocation Frame payload it is transmitted. The hub may send the Allocation Assignment frame any time during RAP or CAP using an unscheduled Post. This is similar to #1 above since the hub may send unscheduled Posts any time outside of scheduled assess. However, it gives a non-deterministic time for which the node must remain in receive mode to wait for the Allocation Assignment frame. The node must also process and reject other frames that are transmitted prior to its Allocation Assignment frame, which could occur over multiple superframes. This could cause unnecessary power consumption by the node. If the node already has a scheduled allocation, the hub may send the Allocation Assignment frame during or after the scheduled allocation interval. Defining a consistent allocation abort mechanism allows this mechanism to function. The Proposed Resolution to S6-499 allows the hub to reclaim an allocation interval when the node has completed its uplink transactions in scheduled uplink or bilink allocations. The hub may also schedule an improvised post to send the Allocation Assignment frame, providing the node supports improvised posts. Proposed Resolution: By implementing the Proposed Resolutions for S6-499 and S7-148, the application and/or implementation may be configured to send the Allocation Request frame appropriately. As such, there is no change recommended specifically for this comment, other than providing narrative explanations on how to respond to an allocation request sent during contention access. <Rick Powell>, <Zarlink> <Rick Powell>, <Zarlink>