doc.: IEEE <doc#>

Slides:



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

<month year> doc.: IEEE /271r0 September, 2000
Submission Title: [Add name of submission]
<month year> <doc.: IEEE doc> May 2015
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
Submission Title: [Recirculation 2 schedule]
doc.: IEEE <doc#>
Submission Title: [WG-Treasurer’s Report July04]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<month year> <doc.: IEEE doc> March 2011
doc.: IEEE <doc#>
March 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Toumaz response to TG6 Call for Applications]
<month year> <doc.: IEEE doc> April 2015
<May,2009> doc.: IEEE <doc .....> <July 2009>
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
<month year> doc.: IEEE <xyz> January 2001
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improved Delayed ACK response Frame for.
Submission Title: [Common rate resolution]
<month year> <doc.: IEEE doc> September 2015
Submission Title: [Resolutions for CID 85, 86, and 87]
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 <030158r0> September 2003
<month year> <doc.: IEEE doc> March 2015
<month year> doc.: IEEE <xyz> November 2000
Submission Title: [IEEE WPAN Mesh Reference Model]
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
Submission Title: [Frame and packet structure in ]
<month year> <doc.: IEEE doc> May 2015
<month year>20 Jan 2006
<month year> doc.: IEEE <030158r0> January 2004
doc.: IEEE <doc#>
Sept 2004 doc.: IEEE a Nov 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
doc.: IEEE <doc#>
April 19 July 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: WNG Closing Report for San Diego.
<month year> <doc.: IEEE doc> March 2015
doc.: IEEE <doc#1>
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
<month year> <doc.: IEEE doc> March 2015
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [ e Schedule Update]
<month year> <doc.: IEEE doc> July 2015
doc.: IEEE <doc#1>
Submission Title: [LB 28 Results] Date Submitted: [14 March 2005]
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
doc.: IEEE < nnn-00-0mag>
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.
doc.: IEEE <doc#1>
<month year> <doc.: IEEE doc> September 2015
doc.: IEEE <doc#1>
Doc.: IEEE Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Summary.
<month year> <doc.: IEEE doc> March 2015
Submission Title: [Common rate resolution]
Submission Title: [Common rate resolution]
July 2003 doc.: IEEE <03/242> July 2003
Jan 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TeraHertz Closing Report Date Submitted: January.
May 2015 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Source identification Date Submitted: May, 2015.
November 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [21.
Presentation transcript:

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> Jan 2013 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Interframe Spacing and Turnaround Requirements] Date Submitted: [Jan 10th, 2013] Source: [Rick Powell] Company [Microsemi] Address [15822 Bernardo Center Dr, Ste B, San Diego, CA, 92127] Voice:[+01-858-675-3485] FAX :[+01-858-675-3450] E-Mail:[rick.powell@microsemi.com ] Re: [In response to TG4k Sponsor Ballot] Abstract: [This presentation discusses the relationship between Interframe Spacing requirements and Turnaround requirements.] 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 (Microsemi) Rick Powell (Microsemi)

Interframe Spacing and Turnaround Requirements Jan 2013 Interframe Spacing and Turnaround Requirements Jan 10, 2013 Rick Powell, Microsemi Rick Powell (Microsemi)

July 2012 doc.: IEEE 802.15-12/0626r0 Jan 2013 Abstract This presentation discusses the relationship between Interframe Spacing requirements and Turnaround requirements. Rick Powell (Microsemi) Rick Powell (Microsemi)

Jan 2013 Definitions Turnaround Time – A PHY constant that defines how quickly a PHY must be capable of transitioning from Tx to Rx, and from Rx to Tx, from the end of the last chip/symbol of one PPDU to the beginning of the first chip on the next PPDU. This is defined as the “maximum” time that the PHY must be capable of making the transition, i.e., less that or equal to “aTurnaroundTime.” Interframe Spacing (IFS) – The time interval between frames, from the end of the of one PPDU until the beginning of the next. Interframe Spacing is a MAC requirement, in that the MAC has “minimum” interval requirements between various frame transactions. IFS includes both back-to-back frames transmitted by the same device, and turnaround IFS, such as Data Frame to ACK Frame. In sub-clause 5.1.1.3, IFS is defined as “minimum” frame separation interval. Rick Powell (Microsemi)

Issues with Turnaround Requirements Jan 2013 Issues with Turnaround Requirements In 802.15.4, sub-clause 8.2.1 & 8.2.2, it states that both the Tx to Rx and Rx to Tx turnaround times are less than or equal to aTurnaroundTime. If the Tx-Rx device is allowed aTurnaroundTime to prepare for the first symbol/chip, but the Rx-Tx device starts transmitting in less than that time (as is allowed by the definition) then the Tx-Rx device will miss part of the PPDU. aTurnaroundTime Device 1 Tx Data Frame Receiver Ready Device 2 Receiver Ready Tx ACK Frame Rx-TxTurnaround IFS < aTurnaroundTime Slide 5 Rick Powell (Microsemi)

Issues with Turnaround Requirements, cont. Jan 2013 Issues with Turnaround Requirements, cont. For proper reception of the ACK Frame, the turnaround of the Tx-Rx device must be less than or equal to the turnaround of the Rx-Tx device. Another way to state this is: The IFS from Data Frame to Ack Frame must be greater than or equal to aTurnaroundTime, if the maximum allowable Tx to Rx turnaround interval is aTurnaroundTime. Device 1 aTurnaroundTime Tx Data Frame Receiver Ready Device 2 Receiver Ready Tx ACK Frame IFS >= aTurnaroundTime Slide 6 Rick Powell (Microsemi)

Issues with Turnaround Requirements, cont. Jan 2013 Issues with Turnaround Requirements, cont. The IFS interval following an ACK to the next Data Frame is LIFS, if the previous MPDU was greater than 18 octets. LIFS is defined as 40 symbol periods, but aTurnaroundTime is 12 symbols or 1 msec, both of which can be less than LIFS. There are cases such as the LIFS below where the turnaround time must be greater than, aTurnaroundTime. Does this violate the PHY turnaround requirement as defined in 8.2.1 and 8.2.2? tack LIFS Device 1 Long Frame RxRdy Long Frame tack LIFS Device 2 Receiver Ready ACK Receiver Ready LIFS> aTurnaroundTime Slide 7 Rick Powell (Microsemi)

Issues with Turnaround Requirements, cont. Jan 2013 Issues with Turnaround Requirements, cont. Tack turnaround IFS is defined in sub-cause 5.1.6.4.2 to be between SIFS and SIFS + aUnitBackoffPeriod. Tack can be greater than aTurnaroundTime. Does this violate the PHY turnaround requirement as defined in 8.2.1 and 8.2.2? tack LIFS Device 1 Long Frame RxRdy Long Frame tack LIFS Device 2 Receiver Ready ACK Receiver Ready LIFS> aTurnaroundTime Slide 8 Rick Powell (Microsemi)

Jan 2013 Conclusions The PHY requirement for turnaround needs to be modified. It should state that this “maximum” time is the capability of the PHY, but not necessarily the behavior of the PHY in all cases. If an LIFS interval is required during a turnaround, then it should not imply a violation of the PHY turnaround requirement. The actual turnaround time is variable, and should be controlled by the MAC based on its IFS requirements and the turnaround capability of the PHY. If the MAC needs more processing time before transmitting an ACK or responding to a Data Request, this should be a defined as an IFS requirement, not a PHY turnaround requirement. The requirements must also be written in such a way that it ensures that the Rx-Tx turnaround does not occur before the Tx-Rx turnaround. MAC timeout requirements, such as macAckWaitDuration, should take into account both IFS and PHY turnaround requirements. Slide 9 Rick Powell (Microsemi)