1 / 37

Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Argument for PNC Controlled Latency] Date Submitted: [January 17, 2004] Source: [John Sarallo, Mark Schrader] Company [Appairent] Address [150 Lucius Gordon Drive, West Henrietta, NY 14586]

pegeen
Download Presentation

Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Argument for PNC Controlled Latency] Date Submitted: [January 17, 2004] Source: [John Sarallo, Mark Schrader] Company [Appairent] Address [150 Lucius Gordon Drive, West Henrietta, NY 14586] Voice:[+1 585 727-2014], FAX: [+1 585 214-2461], E-Mail:[sarallo@appairent.com] Re: [15-04-0610-02-003b] Abstract: [Describes how the PNC could provide a requested latency when granting channel time] Purpose: [A presentation to add information to the discussion of whether 802.15.3 stream creationrequests 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 802.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 802.15. John Sarallo, Mark Schrader - Appairent

  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µsCTAs per superframe) • The 802.15.3 standard states “If multiple CTAs per superframe were requested by the DEV in the Channel Time Request command, as described in 7.5.6.1, 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? John Sarallo, Mark Schrader - Appairent

  3. Best Possible Answer • Those unfamiliar with the details of the 802.15.3 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 802.15.3 MAC know this is not possible because… 1.5ms 0 5 10ms Superframe John Sarallo, Mark Schrader - Appairent

  4. 802.15.3 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 John Sarallo, Mark Schrader - Appairent

  5. Real Answer? • 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 inter-CTA spacing is now 2.0ms 2.0ms BCN CAP 0 5 10ms CTAP Superframe John Sarallo, Mark Schrader - Appairent

  6. But the CTAP is Shared • 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 inter-CTA spacing for the blue stream is now 5.0ms 2.0ms 3.0ms BCN CAP 0 5 10ms CTAP Superframe John Sarallo, Mark Schrader - Appairent

  7. Worst Case Scenario • The time is available and granted by the PNC, but only as one contiguous block of time. • The worst case time inter-CTA spacing is the Superframe Duration minus the total time requested per superframe. In this case 10ms – 2.5ms = 7.5ms (5x worse than expected?) 4.0ms 3.5ms BCN CAP 0 5 10ms CTAP Superframe John Sarallo, Mark Schrader - Appairent

  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 latency delivered may change, thus DEVs must monitor CTAs John Sarallo, Mark Schrader - Appairent

  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 data throughput as channel conditions change. John Sarallo, Mark Schrader - Appairent

  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. John Sarallo, Mark Schrader - Appairent

  11. DEV Procedure • After determining the amount of time needed per superframe to support a specific data rate, and the desired maximum 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 – TimeRequiredPerSF) 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 will suffice. John Sarallo, Mark Schrader - Appairent

  12. DEV Procedure (Cont.) • If a Superrate request is required, the DEV calculates the required CTA Superrate Factor using the formula: SuperrateFactor = (SuperframeDuration – TimeRequiredPerSF) / MaxCTASpacing The result is rounded up to the next integer value. If a Subrate request will suffice, the DEV calculates the maximum CTA Subrate Factor using the formula:SubrateFactor = MaxCTASpacing/(SuperframeDuration – TimeRequiredPerSF) The result is rounded down to the next power of 2. John Sarallo, Mark Schrader - Appairent

  13. DEV Procedure (Cont.) • If a Superrate request is required, the DEV calculates the amount of time to request using the formula: TimeRequested = TimeRequiredPerSF If a Subrate request will suffice, the DEV calculates the amount of time to request using the formula: TimeRequested = SubrateFactor * TimeRequiredPerSF John Sarallo, Mark Schrader - Appairent

  14. PNC Procedure • When the PNC receives a Superrate Channel Time Request, it calculates the maximum inter-CTA spacing required 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= (SubrateFactor * SuperframeDuration) – TimeRequested John Sarallo, Mark Schrader - Appairent

  15. PNC Procedure (Cont.) • 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 TU size can be provided without disrupting the inter-CTA spacing and TU size requirements of existing streams. John Sarallo, Mark Schrader - Appairent

  16. Example 1 • Assume the superframe structure below with an existing 4ms stream that has a 6ms maximum inter-CTA requirement and a TU size of 2ms BCN CAP 10ms 0 5 CTAP Superframe John Sarallo, Mark Schrader - Appairent

  17. Example 1 (Cont.) • Assume a DEV requests 2.0ms of channel time per Superframe with a maximum inter-CTA spacing of 2.0ms and a 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 – TimeRequiredPerSF) = 2 * (10ms – 2ms) = 16ms • The maximum inter-CTA spacing required (2ms) is less than 16ms so a Superrate request is required. • The DEV then calculates a Superrate Factor : SuperrateFactor = (SuperframeDuration – TimeRequiredPerSF) / MaxCTASpacing = (10ms – 2ms) / 2 ms = 8ms / 2ms = 4 • The DEV then calculates the amount of time to request : TimeRequested = TimeRequiredPerSF = 2ms John Sarallo, Mark Schrader - Appairent

  18. 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 TU size of the existing stream. John Sarallo, Mark Schrader - Appairent

  19. Example 1 (Cont.) • 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. Time / Inter-CTA / TU Size 4ms / 6ms / 2.0ms 4ms / 2ms / 0.5ms BCN CAP 0 5 10ms CTAP Superframe John Sarallo, Mark Schrader - Appairent

  20. Example 2 • Assume the superframe structure below with an existing 4ms stream with a 3ms maximum inter-CTA requirement and a TU size of 2ms. BCN CAP 0 5 10ms CTAP Superframe John Sarallo, Mark Schrader - Appairent

  21. Example 2 (Cont.) • Assume a DEV desires 4.0ms of channel time per Superframe with a maximum inter-CTA spacing of 2.0ms and a TU size of 1ms. • The DEV determines if it needs to ask for a Subrate or a Superrate channel time request: 2 * (SuperframeDuration – TimeRequiredPerSF) = 2 * (10ms – 4ms) = 12ms • The maximum inter-CTA spacing (2ms) is less than 12ms so a Superrate request is required. • The DEV then calculates a Superrate Factor : SuperrateFactor = (SuperframeDuration – TimeRequiredPerSF) / MaxCTASpacing = (10ms – 4ms) / 2 ms = 6ms / 2ms = 3 • The DEV then calculates the amount of time to request : TimeRequested = TimeRequiredPerSF = 4ms John Sarallo, Mark Schrader - Appairent

  22. 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 TU size requirements of the existing stream. John Sarallo, Mark Schrader - Appairent

  23. Example 2 (Cont.) • The 4ms of time is available but there is no possible CTA allocation that preserves the inter-CTA spacing and TU size of both streams. Therefore, the new request is denied. Time / Inter-CTA / TU Size 4ms / 3ms / 2.0ms 4ms / 2ms / 1.0ms 2.0ms 2.0ms BCN CAP 3.0ms 1.0ms BCN CAP 0 5 10ms CTAP Superframe John Sarallo, Mark Schrader - Appairent

  24. Example 3 • Assume the superframe structure below and an existing 4ms stream with a 3ms maximum inter-CTA requirement and a TU size of 2ms. BCN CAP 0 5 10ms CTAP Superframe John Sarallo, Mark Schrader - Appairent

  25. Example 3 (Cont.) • Assume a DEV desires 1ms of channel time per Superframe with a maximum inter-CTA spacing of 50ms and a TU size of 1ms. • The DEV determines if it needs to ask for a Subrate or a Superrate channel time request: 2 * (SuperframeDuration – TimeRequiredPerSF) = 2 * (10ms – 1ms) = 18ms • The maximum inter-CTA spacing is greater than 18ms so a Subrate request will suffice. • The DEV then calculates the Subrate Factor : SubrateFactor = MaxCTASpacing/ (SuperframeDuration – TimeRequiredPerSF) = 50ms / (10ms – 1ms) = 50ms / 9ms = 5.55 = 4 John Sarallo, Mark Schrader - Appairent

  26. Example 3 (Cont.) • The DEV then determines the actual Subrate or Superrate Factor it will actually request and the amount of time to request for that Subrate/Superrate Factor from the PNC :  Assume DEV requests a Subrate Factor of 4 John Sarallo, Mark Schrader - Appairent

  27. Example 3 (Cont.) • When the PNC receives the Subrate Channel Time Request from the DEV, it can be assured that the maximum inter-CTA spacing indicated through the Subrate Factor requested will meet or beat the actual desired maximum inter-CTA spacing for the stream. MaxCTASpacing= (SubrateFactor * SuperframeDuration) – TimeRequested = (4 * 10ms) - 4ms = 40ms – 4ms = 36ms • Note that the calculated inter-CTA spacing is less than the original requirement of 50ms. John Sarallo, Mark Schrader - Appairent

  28. Example 3 (Cont.) • The PNC would only grant the request if it can provide the 4ms of channel time every 4th superframe without disrupting the inter-CTA spacing or TU size requirements of the existing stream. • The PNC may allocate one or more CTAs during the subrate superframe to satisfy the request since this can only improve the inter-CTA spacing provided. John Sarallo, Mark Schrader - Appairent

  29. Example 3 (Cont.) Time / Inter-CTA / TU Size 4ms / 3ms / 2.0ms 1ms / 50ms / 1.0ms • There is a CTA allocation possible that can satisfy the needs of both streams so the new request is granted SF n 0 5 10ms SF n+1 0 5 10ms SF n+2 0 5 10ms SF n+3 0 5 10ms SF n+4 0 5 10ms John Sarallo, Mark Schrader - Appairent

  30. Benefits of Proposal • PNC can make more intelligent decisions about which stream requests to grant or deny. • PNC can 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. John Sarallo, Mark Schrader - Appairent

  31. 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 per superframe, the different maximum inter-CTA spacings that can be requested using CTA Rate Type and Factor are shown below: RateTypeRateFactorInterCTASpace(ms)Delta(ms) Superrate 8 1.000 Superrate 7 1.143 .143Superrate 6 1.333 .190Superrate 5 1.600 .270Superrate 4 2.000 .400Superrate 3 2.667 .667 Superrate 2 4.000 1.333Superrate 1 8.000 4.000Subrate 2 16.000 8.000Subrate 4 32.000 16.000Subrate 8 64.000 32.000 John Sarallo, Mark Schrader - Appairent

  32. 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. John Sarallo, Mark Schrader - Appairent

  33. 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. John Sarallo, Mark Schrader - Appairent

  34. Additional Slides • The following slides provide information about how the presented formulas were determined. John Sarallo, Mark Schrader - Appairent

  35. Formula for SuperrateFactor • For a perfect CTA distribution within a repeating time period the calculation of the time between CTAs is: InterCTASpacing = (SuperframeDuration – TimeRequiredPerSF) / SuperrateFactor • Rearranging: SuperrateFactor = (SuperframeDuration – TimeRequiredPerSF) /InterCTASpacing 1.5ms 0 5 10ms John Sarallo, Mark Schrader - Appairent

  36. R*TSF T1 T2 T1 T2 TCTA TInter Formula for Subrate Factor TInter = (R - 1) * TSF + T2 + T1 Noting: TSF = T1 + TCTA+ T2and then substituting TSF – TCTA for T2+T1 we have TInter = (R – 1) * TSF + TSF – TCTA = R * TSF – TCTA If we define the amount of the total TCTAallocated per superframe as TCPS = TCTA / R and then solve for TCTA = R * TCPS we then have the final form: TInter = R * ( TSF - TCPS ) . Solving for R: R = TInter / ( TSF - TCPS ) Finally, using the presentation terminology: SubrateFactor = InterCTASpacing / ( SuperframeDuration – TimeRequiredPerSF ) John Sarallo, Mark Schrader - Appairent

  37. 0 5 10ms 0 5 10ms 0 5 10ms 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 = 2 * (SuperframeDuration – TimeRequiredPerSF) • For example, if the SuperframeDuration is 10ms and the TimeRequiredPerSF is 1ms, a subrate would only be useful if InterCTASpacing >= 2 * (10ms – 1ms) >= 18ms (Note: TimeRequested = Subrate * TimerRequiredPerSF = 2 * 1ms = 2ms) • 1ms TimeRequiredPerSF requested at a subrate of 2 • TimeRequested with a subrate of 2 is 2ms • Worst case inter-CTA spacing is 18ms John Sarallo, Mark Schrader - Appairent

More Related