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-147] 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-147] Abstract: [Comment resolution for letter ballot 55 for S7-147] Purpose: [Propose Resolution of D0 Comment S7-147] 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-147 Comments relative to Contention Access during non-beacon, non-superframe operation. <Rick Powell>, <Zarlink>

3. D0 Comment S7-147 • Page 78, Sub-clause 7.3.3, Line 3 • Comment: Non-Beacon mode without superframe boundaries requires contention access. Contention access is required to connect to a network. How are collisions prevented during unscheduled polling and posting without performing LBT?. • Proposed Change: Only contention access is allowed in Non-Beacon mode without superframe boundaries. In this mode, the Hub may perform Contention access for both Polls and Posts. • Analysis: Since collision access is allowed for the connection process, and there is no restriction on using connection access during non-beacon, non-superframe boundary mode, there needs to be further definition on the use of CSMA during non-beacon, non-superframe boundary mode. There also needs to be further definition on the access by the hub during contention access when using unscheduled polling. <Rick Powell>, <Zarlink>

4. Proposed Resolution: Change “7.3.3 Non-beacon mode without superframe boundaries” From: In this mode, a hub may provide only unscheduled type-II polled allocations, as illustrated in Figure 60. To: In this mode, a hub may provide only unscheduled type-II polled allocations, as illustrated in Figure 60. A hub may also support contented access methods, as defined in sections subsections 7.5.1, with the exception that back-off periods for contention access are relative to the beginning of the contention access process of the node. Change ” 7.6.1 Unscheduled access” from: A hub may employ unscheduled polling and posting access to send polls or posts at any time to grant polled or posted allocations either in beacon mode or non-beacon mode as characterized in 7.3, so long as the addressed nodes indicated that they will always be in active state through their last transmitted MAC Capability field (i.e., with Always Active bit set to 1). A node that has so indicated shall constantly be in active state ready to receive unscheduled polls or posts. To: A hub may employ unscheduled polling and posting access to send polls or posts at any time within non-contention access periods in superframe mode, or anytime in non-superframe mode, to grant polled or posted allocations either in beacon mode or non-beacon mode as characterized in 7.3, so long as the addressed nodes indicated that they are capable of receiving unscheduled polls through their last transmitted MAC Capability field. When performing unscheduled polling and posting during contention access, the hub shall not start transmission of the poll or post when another node is in the process of transmission a frame. <Rick Powell>, <Zarlink>