Doc.: IEEE 802.15-04/610r0 Submission November 2004 John Sarallo, AppairentSlide 1 Project: IEEE 802.15 Working Group for Wireless Personal Area Networks.

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0136r0 Submission March 2006 Abbie Mathew, NewLANS Project: IEEE P Working Group for Wireless Personal Area Networks Submission.
Advertisements

Doc.: IEEE /037r0 Submission January 2003 Ed Callaway, Motorola Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
July 2004 Jay Bain, Fearn Consulting doc.: IEEE /0379r0 Submission Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE /080r0 Submission February 2004 Welborn, MotorolaSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE Submission Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed.
Doc.: IEEE Submission November 2003, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE c Submission Slide 1 April, 2008 NICT Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc: IEEE Submission April 2015 Hernandez,Li,Dotlić,Miura (NICT)Slide 1 Project: IEEE P Working Group for Wireless Personal.
e Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [The embedded.
Doc.: b Submission Mar Song-Lin Young[Sharp Labs.] Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE /317r0 Submission September, 2000 Allen Heberling, Eastman Kodak, CompanySlide 1 NOTE: Update all red fields replacing with your information;
Doc.: IEEE Submission September 2013 Li, Hernandez, Dotlic, Miura, NICT Slide 1 Project: IEEE P Working Group for Wireless.
Doc.: IEEE /115r0 Submission February 2001 Mark Schrader, Eastman Kodak Co.Slide 1 Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE /115r1 Submission February 2001 Mark Schrader, Eastman Kodak Co.Slide 1 Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE /315r1 Submission July 2001 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANS) Submission Title: [Power Control and Automatic Frequency Offset Control.
Doc.: IEEE c SubmissionSlide 1 Qualcomm 2/29/2016 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.IEEE b Submission Nov 2004 Liang Li, WXZJ Inc. Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
March 2004 Jay Bain, Fearn Consulting; Knut Odman, Motorola doc.: IEEE /0142r0 Submission Project: IEEE P Working Group for Wireless Personal.
Submission November 2015 Slide 1Li Qiang, Huawei Technologies Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE /076r1 Submission Feb Dr. William ShvodianSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE COEX-02/004r0 Submission 23 January, 2001 James P. K. Gilb, Appairent Technologies Project: IEEE P Working Group for Wireless Personal.
Slide 1 SEPT doc.: c Submission Clint Powell, Kuor-Hsin Chang - Freescale, Inc. Project: IEEE P Working Group for Wireless.
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Communicating.
Doc.: IEEE a Submission Jan Li Qiang, HuaweiSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE /yyyr0 Submission Aug 2001 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE /440r2 Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE :
Doc.: IEEE e Submission July 2009 Andy Summers, Skip Ashton, EmberSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE /076r0 Submission Feb Dr. William ShvodianSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IEEE
doc.: IEEE <doc#>
Submission Title: [Add name of submission]
doc.: IEEE <01/xxx>
May 2000 doc.: IEEE /109r0 May 2000 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: WPAN Requirements.
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
July 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Bi-Directional CTA] Date Submitted: [July.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
23 January, 2001 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Overview of Draft Standard ]
Submission Title: [Compromise Proposal] Date Submitted: [12Sept2004]
<January 2002> doc.: IEEE <02/139r0> 12/8/2018
<January 2002> doc.: IEEE <02/139r0> 12/29/2018
Submission Title: IEEE : Management Slots in the MAC.
Submission Title: [Common rate resolution]
doc.: IEEE <doc#>
Submission Title: IEEE : Management Slots in the MAC.
November 2015 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Text Proposal for FCC NPRM Response Date.
Submission Title: [Compromise Proposal] Date Submitted: [12Sept2004]
Submission Title: [Shared GTS Structure]
Mar Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [CTA Advertisement for Overlapping Piconets]
Sept 2004 doc.: IEEE b Sept 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
<month year> doc.: IEEE <xyz> November 2000
<month year> doc.: IEEE / January 2005
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
doc.: IEEE <doc#>
November 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Simplified geometry for the usage model.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<January 2002> doc.: IEEE <02/139r0> Nov, 2008
November 2015 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Text Proposal for FCC NPRM Response Date.
doc.: IEEE <doc#>
doc.: IEEE <01/xxxr0>
July 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Bi-Directional CTA] Date Submitted: [July.
Submission Title: [Extend-Superframe and GTS Structure]
July 9, 2001 IEEE /328r0 Nov. 12, 2001 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: MAC CTRB.
Submission Title: [Argument for PNC Controlled Latency]
doc.: IEEE <doc#1>
August, 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improve the latency between GTS request.
Submission Title: [Common rate resolution]
Submission Title: [Common rate resolution]
Presentation transcript:

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 1 Project: IEEE Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Argument for PNC Controlled Latency] Date Submitted: [November 13, 2004] Source: [John Sarallo] Company [Appairent] Address [150 Lucius Gordon Drive, West Henrietta, NY 14586] Voice:[ ], FAX: [ ], Re: [ b] Abstract:[Describes why the PNC should provide a requested latency when granting channel time] Purpose:[A presentation to add information to the discussion of whether stream creation requests should be time based or based on QoS needs. This document argues that latency should be provided by the PNC and that this can be done using the existing Channel Time Request command.] Notice:This document has been prepared to assist the IEEE 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

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 2 Channel Time Request Example Assume a Superframe Duration of 10ms Assume a DEV is granted 2.5ms of channel time per superframe with a Superrate Rate Factor of 5 (Five 500µs CTAs per superframe) The standard states “If multiple CTAs per superframe were requested by the DEV in the Channel Time Request command, as described in , the PNC shall attempt to spread the CTAs out evenly within the superframe.” What is the worst case time between any two consecutive CTAs if this above request is granted?

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 3 Best Possible Answer Those unfamiliar with the details of the MAC may assume CTAs are perfectly distributed throughout the 10ms Superframe, arriving once every 2.0ms, with maximum inter-CTA spacing of 1.5ms Those familiar with the details of the MAC know this is not possible because… Superframe 0510ms 1.5ms

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide Superframe Structure A Superframe contains a Beacon and a variable sized Contention Access Period (CAP) CTAs are actually distributed throughout the Channel Time Allocation Period (CTAP) only

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 5 For simplicity, let us assume that the Beacon and the CAP consume 2ms of the 10ms Superframe When we distribute the 5 CTAs in this superframe, the worst case time between any two consecutive CTAs is now 2.0ms Real Answer? CTAP 0510ms CAPBCN 2.0ms Superframe

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 6 What if another stream existed when the request was granted (or more interestingly, created after) If the PNC chose the above distribution of CTAs, the worst case time between any two consecutive blue CTAs is now 5.0ms But the CTAP is Shared 0510ms CAPBCN 2.0ms CTAP Superframe 3.0ms

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 7 The time is available and granted by the PNC, but only as one contiguous block of time. The worst case time between consecutive CTAs is the Superframe Duration minus the total time requested per superframe. In this case 10ms – 2.5ms = 7.5ms (5x worse than expected?) Worst Case Scenario 0510ms CAPBCN 4.0ms3.5ms CTAP Superframe

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 8 Observations If the PNC grants requests based solely on the time requested, and merely “attempts” to spread the CTAs evenly within the superframe, the requesting DEV may not receive the latency (the maximum inter-CTA spacing) that it requires. The DEV can only determine the actual latency received once the CTAs arrive in the Beacon. The DEV must then monitor the CTAs to detect changes in the current latency received.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 9 What if ? What if the PNC granted requests based on both the time requested and a requested inter-CTA spacing? The PNC would directly maintain the inter-CTA spacing of streams. The PNC would determine Subrate/Superate requirements based on inter-CTA spacing needs and the current Superframe Duration. The PNC could deny future stream requests if granting the request would violate the inter-CTA spacing needs of existing streams. Each DEV would still be responsible for maintaining other QoS parameters such as throughput.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 10 How ? The best solution would be to add a specific inter-CTA spacing (or latency) value to the channel time request, but this would require a change to the over-air command. Alternatively, the PNC could interpret the CTA Rate Type and CTA Rate Factor as an actual inter-CTA spacing value using the current Superframe Duration as a reference.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 11 DEV Procedure 1.After determining the amount of time needed per superframe and the desired inter-CTA spacing, the DEV would decide if it needs to ask for a Subrate or a Superrate Channel Time Request. To do this, it compares the maximum inter-CTA spacing required to the following value: (2 * SuperframeDuration) – TimeRequested If the maximum inter-CTA spacing required is less than the computed value, then a Superrate request is required. If the maximum inter-CTA spacing required is equal to or greater than the computed value, then a Subrate request is required.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 12 DEV Procedure (Cont.) 2.If a Superrate request is required, the DEV calculates the required CTA Rate Factor using the formula: SuperrateFactor = (SuperframeDuration – TimeRequested) / MaxCTASpacing The result is rounded up to the next integer value. If a Subrate request is required, the DEV calculates the required CTA Rate Factor using the formula: SubrateFactor = (MaxCTASpacing + TimeRequested) / SuperframeDuration The result is rounded down to the next power of 2.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 13 PNC Procedure 1.When the PNC receives a Superrate Channel Time Request, it calculates the maximum inter-CTA spacing required using using the formula: MaxCTASpacing = (SuperframeDuration – TimeRequested) / SuperrateFactor If a Subrate Channel Time Request is received, the PNC calculates the maximum inter-CTA spacing required using the formula: MaxCTASpacing = (SuperframeDuration * SubrateFactor) - TimeRequested

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 14 PNC Procedure (Cont.) 2.The PNC grants the channel time request if the requested time per superframe is available AND if the CTAs can be allocated in such a way that the requested maximum inter-CTA spacing and minimum TU size can be provided without disrupting the inter-CTA spacing and minimum TU size of existing streams.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 15 Assume the superframe structure below with an existing 4ms stream that has a 6ms maximum inter-CTA requirement and a minumum TU size of 2ms Example ms CAPBCN CTAP Superframe

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 16 Example 1 (Cont.) Assume a DEV requests 2.0ms of channel time with a maximum inter-CTA spacing of 2.0ms and a minimum TU size of 0.5ms. First, the DEV determines if it needs to ask for a Subrate or a Superrate channel time request: (2 * SuperframeDuration) – TimeRequested = (2 * 10ms) – 2ms = 18ms. The maximum inter-CTA spacing required (2ms) is less than 18ms so a Superrate request is required. The DEV then calculates a Superrate Factor : SuperrateFactor = (SuperframeDuration – TimeRequested) / MaxCTASpacing = (10ms – 2ms) / 2 ms = 8ms / 2ms = 4

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 17 Example 1 (Cont.) When the PNC receives the Superrate Channel Time Request from the DEV, it calculates the desired maximum inter-CTA spacing using using the formula: MaxCTASpacing = (SuperframeDuration – TimeRequested) / SuperrateFactor = (10ms – 2ms) / 4 = 8ms / 4 = 2ms The PNC would only grant the request if it could provide both the 2ms of time per superframe and the calculated maximum inter-CTA spacing of 2ms without disrupting the inter-CTA spacing or minimum TU size of the existing stream.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 18 There is a CTA allocation possible that can satisfy the needs of both streams so the new request is granted. Note that the PNC automatically increased the superrate factor for the existing stream in order to grant the request. Example 1 (Cont.) CTAP 0510ms CAPBCN Superframe Time / Inter-CTA / Min TU 4ms / 6ms / 2.0ms 4ms / 2ms / 0.5ms

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 19 Assume the superframe structure below with an existing 4ms stream with a 3ms maximum inter-CTA requirement and a minimum TU size of 2ms. Example ms CAPBCN CTAP Superframe

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 20 Example 2 (Cont.) Assume a DEV desires 4.0ms of channel time with a maximum inter-CTA spacing of 2.0ms and a minimum TU size of 1ms. The DEV determines if it needs to ask for a Subrate or a Superrate channel time request: (2 * SuperframeDuration) – TimeRequested = (2 * 10ms) – 4ms = 16ms. The maximum inter-CTA spacing (2ms) is less than 16ms so a Superrate request is required. The DEV then calculates a Superrate Factor : SuperrateFactor = (SuperframeDuration – TimeRequested) / MaxCTASpacing = (10ms – 4ms) / 2 ms = 6ms / 2ms = 3

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 21 Example 2 (Cont.) When the PNC receives the Superrate Channel Time Request from the DEV, it calculates the desired maximum inter-CTA spacing using using the formula: MaxCTASpacing = (SuperframeDuration – TimeRequested) / SuperrateFactor = (10ms – 4ms) / 3 = 6ms / 3 = 2ms The PNC would only grant the request if it could provide both the 4ms of time per superframe and the calculated maximum inter-CTA spacing of 2ms without disrupting the inter-CTA spacing or minimum TU size of the existing stream.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 22 The 4ms of time is available but there is no possible CTA allocation that preserves the inter-CTA spacing and minimum TU size of both streams. Therefore, the new request is denied. Example 2 (Cont.) 0510ms CAPBCN Time / Inter-CTA / Min TU 4ms / 3ms / 2.0ms 4ms / 2ms / 1.0ms CAPBCN CTAP Superframe 2.0ms 3.0ms 1.0ms

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 23 Assume the superframe structure below and an existing 4ms stream with a 3ms maximum inter-CTA requirement. Example ms CAPBCN CTAP Superframe

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 24 Example 3 (Cont.) Assume a DEV desires 1.0ms of channel with a maximum inter-CTA spacing of 50.0ms. The DEV determines if it needs to ask for a Subrate or a Superrate channel time request: (2 * SuperframeDuration) – TimeRequested = (2 * 10ms) – 1ms = 19ms. The maximum inter-CTA spacing is greater than 19ms so a Subrate request is required. The DEV then calculates a Subrate Factor : SubrateFactor = (MaxCTASpacing + TimeRequested) / SuperframeDuration = (50ms + 1ms) / 10 ms = 51ms / 10ms = 5.1 = 4

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 25 Example 3 (Cont.) When the PNC receives the Subrate Channel Time Request from the DEV, it can be assured that the Subrate Factor requested will meet or beat the desired maximum inter-CTA spacing. MaxCTASpacing = (SuperframeDuration * SubrateFactor) - TimeRequested = (10ms * 4) - 1ms = 40ms – 1ms = 39ms Note that the calculated inter-CTA spacing is less than the original requirement of 50ms. The PNC would grant the request if it could provide the requested 1ms of time every 4 th superframe without disrupting the inter-CTA spacing or minimum TU size of the existing stream.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 26 There is a CTA allocation possible that can satisfy the needs of both streams so the new request is granted. Example 3 (Cont.) 0510ms SF n SF n+1 SF n+2 SF n+3 SF n+4

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 27 Benefits of Proposal PNC can make more intelligent decisions about which stream requests to grant or deny. PNC could maintain the inter-CTA spacing (pseudo- latency) requirements for granted streams. DEVs can count on receiving the inter-CTA spacing that they requested throughout the life of the stream. PNC allocates CTAs in a manner that applications such as 1394 expect. PNC has the information it needs to perform an intelligent re-allocation of CTAs if a change in the superframe duration is required.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 28 Drawbacks of Proposal The granularity of the maximum inter-CTA spacing that can be requested by a DEV is limited, especially for Subrate requests. For example, with a superframe duration of 10ms and a time request of 2ms, the different maximum inter-CTA spacings that can be requested using CTA Rate Type and Factor are shown below : RateType RateFactor InterCTASpace(ms) Delta(ms) Superrate Superrate Superrate Superrate Superrate Superrate Superrate Superrate Subrate Subrate Subrate

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 29 Drawbacks (Cont.) Would this be a change to the interpretation of existing fields in the Channel Time Request command, or was this the intention of Superrate and Subrate requests all along? There is no mechanism for the PNC to inform a DEV about the inter-CTA spacing it could have provided.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 30 Conclusion If the PNC only attempts to distribute requested CTAs evenly within a superframe without clear latency requirements, applications must understand that the latency received may be much higher than expected and that the received latency may change at any time. With latency requirements, the PNC can allocate and maintain the requested latency for each stream. With latency requirements, the PNC can deny new streams if granting the stream will violate the latency requirements of existing streams. The CTA Rate Type and CTA Rate Factor can be used to convey latency information to the PNC.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 31 Additional Slides The following slides provide information about how the presented formulas were determined.

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 32 Formula for SuperrateFactor For a perfect CTA distribution within a repeating time period the calculation of the time between CTAs is: InterCTASpacing = (SuperframeDuration – TotalTimeRequested) / SuperrateFactor Rearranging: SuperrateFactor = (SuperframeDuration – TotalTimeRequested) / InterCTASpacing 0510ms 1.5ms

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 33 Formula for SubrateFactor For a subrate distribution the time between CTAs is: InterCTASpacing = (SuperframeDuration – TotalTimeRequested) + ((SubrateFactor – 1) * SuperframeDuration) = SuperframeDuration – TotalTimeRequested + (SubrateFactor * SuperframeDuration) – SuperframeDuration = (SubrateFactor * SuperframeDuration) – TotalTimeRequested Rearranging: SubrateFactor = (InterCTASpacing + TotalTimeRequested)/ SuperframeDuration 0510ms 05 05

doc.: IEEE /610r0 Submission November 2004 John Sarallo, AppairentSlide 34 Formula for Determining Superrate vs. Subrate For a subrate to be useful, the CTA must be able to arrive at most once every other superframe (a Subrate Factor of 2) The minimum InterCTASpacing required for a Subrate to be useful is therefore determined by using 2 as the Subrate Factor in the formula for determining Subrate InterCTASpacing: InterCTASpacing = (SubrateFactor * SuperframeDuration) – TotalTimeRequested InterCTASpacing = (2 * SuperframeDuration) – TimeRequested 0510ms 05 05