1 / 30

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Modified Channel Time Request Block CTRB Proposal Date Submitted: [9 July 2001] Source: [Karl A. Miller] Company [Aryya Communications]

saul
Download Presentation

Project: IEEE P802.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 P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Modified Channel Time Request Block CTRB Proposal Date Submitted: [9 July 2001] Source: [Karl A. Miller] Company [Aryya Communications] Address [444 North Frederick Ave. Suite 309, Gaithersburg, MD 20877] Voice:[240-683-8803], FAX: [301-947-8964], E-Mail:[kmiller@aryya.com] Re: [] Abstract: Allocation Index to support up to 4 allocations between devices, max allocation delay parameter, and QOS allocation flags added to the Channel Time Request Block. Amount of time allocated and period of allocation are clarified. Purpose: Clarification of Channel Time Request Block with some QOS enhancements. 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. Karl Miller, Aryya Communications

  2. Channel Time Allocation Goals (1) • Unambiguous relationship between stream QOS and Channel Time Request. That is, for a given set of stream QOSs between device-pairs, the device knows how to send appropriate Channel Time Requests to the PNC to support the set of streams. • Interoperability - Support Predictable and Deterministic GTS allocation methods for the PNC. Karl Miller, Aryya Communications

  3. Channel Time Allocation Goals (2) • Interoperability - Bounded performance on such matters as latency and “allocation delay” so that the device can be designed to operate in a variety of PNC/superframe environments. Karl Miller, Aryya Communications

  4. Channel Time Request Block (CTRB) • The Channel Time Request Block (CTRB) is the structure within the Channel Time Request frame specifying the time bandwidth request. It is sent from the requesting device to the PNC. • The PNC uses the CTRBs from the devices to determine how GTSs are allocated within the superframe. The result is the CTAs contained in the Beacon frame. Karl Miller, Aryya Communications

  5. Summary of CTRB Changes (1) • “Slot Times” are now called “Allocation Periods” since more than one GTS (slot) may be used to satisfy allocation.“Allocation Period Length” and “Time Requested Per Period” define the time bandwidth request. • 2-bit Allocation Index added to CTRB.Same 2-bit Allocation Index added to CTA in Beacon (2-bits taken from the CTA “Time Slot Duration” field). Karl Miller, Aryya Communications

  6. Summary of CTRB Changes (2) • “Maximum Allocation Delay” parameter added to allow designer to size jitter/latency buffer independent of beacon interval. • Async/Isoch flag provided to aid in QOS allocation policy. • “Multi-GTS Superframe” and “Single-GTS per Period” flag to limit fragmentation. Karl Miller, Aryya Communications

  7. Old Channel Time Request Block 6 Octet Channel Time Request Block (CTRB from 292r1) : • Stream ID (2 octets) • Duration Between time-slots, Kus resolution(1 octet) • Minimum channel Time in a time slot, 32us resolution (1 octet) • Requested Channel Time Per Time Slot , 8 us resolution (2 octets) Karl Miller, Aryya Communications

  8. New Channel Time Request Block 10 octet CTRB : • Peer Device Address (1 octet) • Allocation Flags (1 octet) • Allocation Period Length (2 octets), 8 us resolution • Time Requested per Period (2 octets), 8 us resolution • Maximum Allocation Delay (2 octets), 8 us resolution – isochronous only • Minimum Size GTS (2 octets), 8 us resolution Karl Miller, Aryya Communications

  9. Allocation Period Length • The CTRB Allocation Period Length is the amount of time during which the requested allocation will be attempted by the PNC. • This Allocation Period Length corresponds to the “Duration Between time-slots” of the CTRB from 292r1. • The resolution has been changed from “Kus” to 8 us to more closely indicate the amount of bandwidth the user is requesting. Note : “Kus” resolution is too crude to request bandwidth with sufficient accuracy Karl Miller, Aryya Communications

  10. Time Requested Per Period (1) • The CTRB “Time Requested Per Period” is the amount of time being requested for allocation in each “Allocation Period”. • The CTRB “Time Requested Per Period” field corresponds to the “Requested Channel Time Per Time Slot” of the CTRB spec’ed in 292r1 • More than one GTS may be allocated during each “Allocation Period” to supply the requested time (unless the “Single-GTS per Period” flag is set). Karl Miller, Aryya Communications

  11. Time Requested Per Period (2) • The Async/Isoch Allocation flag is used to determine how much of the bandwidth must be provided. Isochronous traffic requires all the bandwidth requested in every Allocation Period. Asychronous traffic may be provided with less bandwidth in an individual Allocation Period. • The “Time Requested Per Period” is chosen by the device and does NOT need to correspond to any multiple or fraction of the beacon interval Karl Miller, Aryya Communications

  12. Beacon Interval Superframe 1 Superframe 2 Superframe 3 Allocation Period 1 Allocation Period 2 Allocated Time (GTSs) Allocated Time (GTSs) Time Requested per Period Allocation Period Length Relationship Between Intervals Karl Miller, Aryya Communications

  13. Maximum Allocation Delay (1) • The “Maximum Allocation Delay” parameter is the maximum amount of time from the start of the Allocation Period that all GTS time must be provided to the allocation. • Time provided after this delay period arrives too late for the device to use. • This parameter ONLY applies to isochronous streams. Karl Miller, Aryya Communications

  14. Maximum Allocation Delay (2) • The starting point of the Allocation Periods is based on the first GTS ever allocated for the allocation. • The Allocation Period Length is used with the starting point of Allocation Periods to calculate the starting time of each Allocation Period. The maximum delay is applied to those Allocation Period start times. Karl Miller, Aryya Communications

  15. Maximum Allocation Delay (3) • The “Maximum Allocation Delay” parameter helps the application/device bound the amount of jitter/latency buffer it needs to create an isochronous stream. • The “Maximum Allocation Delay” parameter allows design decisions to be made without knowing what the eventual beacon period may be. Karl Miller, Aryya Communications

  16. Maximum Allocation Delay (4) • Example : An isochronous device has a jitter/latency memory buffer that can smooth out up to 30 ms of jitter/latency between consecutive Allocation Period allocations. By requesting a “Maximum Allocation Delay” of 30 ms from the PNC, the PNC can use a 100 ms beacon, as long as it accomodates the spacing of allocations for the device. • A “Maximum Allocation Delay” request of 0xFFFF indicates “GTS slots can be assigned anywhere in CFP”. • A value of “0” is requesting a strict TDMA allocation without any variance in the location of the allocations (always at start of Allocation Period). Karl Miller, Aryya Communications

  17. New CTRB Allocation Flags 1 octet of Allocation Flags : • Allocation Direction : 1 bit. 0 = CTRB Peer Address is source of the data, 1 = CTRB Peer Address is the destination • Allocation Index : 2 bits (distinguishes up to 4 separate allocations – added to CTA). • Async/Isoch Flag : 1 bit, 0 = Async, 1 = Isochronous • Multi-GTS Superframe Flag : 1 bit, 0 = device wants at most a single GTS within any given superframe. 1 indicates multiple GTSs in a superframe are allowed for fulfilling the allocation. • Single-GTS per Period Flag : 1 bit, 0 = device allows multiple GTSs within an Allocation Period. 1 indicates at most one GTS allowed per Allocation Period. • Reserved : 2 bits – for future expansion Karl Miller, Aryya Communications

  18. New CTRB Traffic Addressing The source and destination traffic address is determined by : • 8-bit Source device address in MAC header of Channel Time Request command frame (MAC_SRC_ADR) • CTRB Peer device address (CTRB_PEER_ADR) • CTRB direction flag (CTRB_DIR_FLAG) If CTRB_DIR_FLAG == 0 Traffic is CTRB_PEER_ADR  MAC_SRC_ADR Else Traffic is MAC_SRC_ADR  CTRB_PEER_ADR Note : This is the same sense as the DSAA “Direction Flag” used in Stream Management. Karl Miller, Aryya Communications

  19. New CTRB Allocation Index • A 2-bit Allocation Index has been added to the CTRB to allow up to 4 different allocations being managed between source-device/destination-device pairs. • The 2-bit Allocation Index would be added to the CTA. Recommend taking 2-bits from the CTA Slot-Duration field (leaving 14-bits, which is more than adequate). • Allocation Index is provided so that a mixture of asynchronous and isochronous allocations can be managed between source/destination pairs. Karl Miller, Aryya Communications

  20. New Allocation Index Usage • Allocation Index does NOT necessarily correspond to a stream between two devices. • Allocation Index allows the PNC to manage a mixture of async allocation with an isochronous allocation. • Allocation Index also allows the PNC to manage a mixture of isochronous allocations which have different “Allocation Period Length” and/or “Maximum Allocation Delay” requests. Karl Miller, Aryya Communications

  21. Minimum-GTS • The CTRB Minimum-GTS field specifies the smallest amount GTS that the application will find usable for this allocation. • The CTRB Minimum-GTS corresponds to “Minimum Requested Channel Time In a Time Slot” spec’ed in 292r1. • The PNC may use multiple GTSs to satisfy the “Time Requested per Period” requested. However each GTS must be at least Minimum-GTS in size. • If the device wants a single GTS to satisfy the “Time Requested per Period”, then it should set the “Single-GTS per Period” flag. Karl Miller, Aryya Communications

  22. Multi-GTS Superframe Flag • Multi-GTS Superframe flag is provided for devices that want at most a SINGLE GTS in any given superframe (value 0).This type of request is for devices that want a simple, unfragmented universe. • This flag is similar to “MAX_GTS == 1”, except that it only applies to an individual allocation (while MAX_GTS == 1 applies to the entire device). Karl Miller, Aryya Communications

  23. Single-GTS per Period Flag • The “Single-GTS per Period” allocation flag indicates a request that at most one GTS is provided for each Allocation Period. • In particular, if the Allocation Period spans multiple superframes, only a single GTS would be allocated during the Allocation Period. • This flag applies to both async and isoch streams. • This flag is provided to devices that need to keep it simple. Karl Miller, Aryya Communications

  24. Allocation Policies (1) • Proposed Mechanism is on a first-come/first-served allocation prioritization (see “Open Issues”). • The primary purpose of the 2-bit Allocation Index is to manage asynchronous and isochronous allocations separately.The requirements of isochronous allocations related to “allocation delay” and “time allocated” are much more rigid than required by asynchronous allocations. Karl Miller, Aryya Communications

  25. Allocation Policies (2) • Device-pairs should consolidate all asynchronous streams into a single async allocation, when possible. This helps “share” the bandwidth between multiple “bursty” streams. • When two isochronous allocations between device-pairs have incompatible timings (“Allocation Period Length/Time Per Period/Maximum Alloc Delay”) separate Allocation Indexes may be used. Karl Miller, Aryya Communications

  26. Allocation Policies (3) • “Time Requested Per Period” is set to 0 to cancel an outstanding reservation. • To request more time for an allocation issue the CTRB with a new “Time Requested Per Period” with a value equal to “previous amount + additional amount” being requested. Karl Miller, Aryya Communications

  27. Allocation Policies (4) • Relative to async allocations, the PNC should remember the bandwidth requested (Time Requested per Period) and provide the maximum possible up to that limit. • When the PNC does not have sufficient async bandwidth, it should reduce the size of all async requests (while respecting the minimum GTS size). Karl Miller, Aryya Communications

  28. Open Issues (1) • Stream QOS has “minimum”, “peak”, and “average” rates. The current “Allocation Period Length” and “Time Requested per Period” combination is really asking for a single rate. Could provide “min”, “peak”, “avg” “Time Requested per Periods” to CTRB (adding 4 additional octets). Note that this is only relevant to asynchronous streams. Karl Miller, Aryya Communications

  29. Open Issues (2) • Stream QOS supports a 3-bit “Priority” (0 – 7).Proposed allocation policy is “first come,first served”.Could add a “priority” field to the proposed CTRB which would be analogous to Stream Priority. Karl Miller, Aryya Communications

  30. Open Issues (3) • Could combine the CTRB with the Stream Management request. Note that the stream index and the allocation index are independent. • Should provide Use Cases for sample applications. Karl Miller, Aryya Communications

More Related