doc.: IEEE <doc#1>

Slides:



Advertisements
Similar presentations
Doc.:IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Advertisements

Doc.:IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Submission Title: [Proposal for MAC Peering Procedure]
Submission Title: [Add name of submission]
Submission Title: Sydney e/ Liaison Report.
Submission Title: St. Louis e/ Liaison Report.
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
doc.: IEEE g-Trends-in-SUN-capacity
September, 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Resolution of D0 Comment S7-386,
doc.: IEEE <doc#>
November 2008 doc.: IEEE November 2008
<month year> doc.: IEEE <030158r0> March 2004
doc.: IEEE <doc#>
Project: IEEE Wireless Personal Area Networks (WPANs)
Submission Title: [Comment Resolutions for #309, #310, and #314]
March 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Toumaz response to TG6 Call for Applications]
doc.: IEEE <doc#1>
Submission Title: [Proposal for MAC Peering Procedure]
<January 2002> doc.: IEEE <02/139r0> 12/29/2018
<month year> doc.: IEEE <xyz> January 2001
Submission Title: IEEE : Management Slots in the MAC.
Submission Title: [Comment Resolutions for #345, #347, #348, and #349]
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improved Delayed ACK response Frame for.
< November, 2011 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [More Low Energy Mechanism Details]
Submission Title: [Common rate resolution]
Submission Title: IEEE : Management Slots in the MAC.
<month year> <doc.: IEEE doc> September 2015
Submission Title: [Proposal for MAC Peering Procedure]
Submission Title: [Comment Resolutions for #309, #310, and #314]
doc.: IEEE <doc#1>
November 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG4c Project Plan] Date Submitted: [15.
<month year> <doc.: IEEE doc> September 2010
doc.: IEEE g-Trends-in-SUN-capacity
< April, 2012 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improvement of Data Transmission in.
<month year> doc.: IEEE <xyz> November 2000
Sept 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed MAC Comment Resolutions Date Submitted:
doc.: IEEE <doc#>
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
doc.: IEEE <doc#>
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
Submission Title: [Proposal for MAC Peering Procedure]
<January 2002> doc.: IEEE <02/139r0> Nov, 2008
September 2000 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG3 Rank Order Voting Process Description.
doc.: IEEE <doc#1>
May 2016 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Timeline of TG4s] Date Submitted: [19 May 2016]
doc.: IEEE <doc#1>
doc.: IEEE <doc#1>
September 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Discussion on MAC functionalities Date.
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
July 2010 <month year> doc.: IEEE g Doc.: IEEE g
March 2017 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Timeline of TG4s] Date Submitted: [16 March.
doc.: IEEE <doc#1>
January 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [17.
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of TG6 Draft D0 comment.
November 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [15.
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
May 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [15 May.
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
doc.: IEEE <doc#1>
November 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG4c Project Plan] Date Submitted: [15.
Source: [Chunhui Zhu] Company [Samsung]
doc.: IEEE <doc#1>
doc.: IEEE <doc#1>
Submission Title: [Common rate resolution]
September 2015 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Timeline of TG4s] Date Submitted: [17.
Submission Title: [Common rate resolution]
July 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [ July.
Presentation transcript:

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: 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> <Rick Powell>, <Zarlink>

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

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

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

doc.: IEEE 802.15-<doc#1> <September 2010> doc.: IEEE 802.15-<doc#1> <September 2010> Proposed Resolution: Change “7.5.1.3 Using 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. 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. 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> <Rick Powell>, <Zarlink>

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