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

July 9, 2001

Karl Miller, Aryya CommunicationsSlide 1

doc.: IEEE 802.15-01/330r0

Submission

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

Submission Title: Modified Channel Time Request Block CTRB ProposalDate 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:[[email protected]]

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

Channel Time Allocation Goals (1)

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.

2) Interoperability - Support Predictable and Deterministic GTS allocation methods for the PNC.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

Channel Time Allocation Goals (2)

3) 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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

Summary of CTRB Changes (1)

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) 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).

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

Summary of CTRB Changes (2)

3) “Maximum Allocation Delay” parameter added to allow designer to size jitter/latency buffer independent of beacon interval.

4) Async/Isoch flag provided to aid in QOS allocation policy.

5) “Multi-GTS Superframe” and “Single-GTS per Period” flag to limit fragmentation.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

Old Channel Time Request Block

6 Octet Channel Time Request Block (CTRB from 292r1) :

1) Stream ID (2 octets)

2) Duration Between time-slots, Kus resolution(1 octet)

3) Minimum channel Time in a time slot, 32us resolution (1 octet)

4) Requested Channel Time Per Time Slot , 8 us resolution (2 octets)

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

New Channel Time Request Block

10 octet CTRB :

1) Peer Device Address (1 octet)2) Allocation Flags (1 octet)3) Allocation Period Length (2 octets), 8 us resolution4) Time Requested per Period (2 octets), 8 us resolution5) Maximum Allocation Delay (2 octets), 8 us resolution

– isochronous only6) Minimum Size GTS (2 octets), 8 us resolution

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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).

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

Relationship Between Intervals

Superframe 1 Superframe 2 Superframe 3

Allocation Period 1 Allocation Period 2

AllocatedTime

(GTSs)

AllocatedTime

(GTSs)

Beacon Interval

Allocation Period Length

Time Requested per Period

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission


• 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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission


• 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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission


• 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).

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

New CTRB Allocation Flags

1 octet of Allocation Flags :

1) Allocation Direction : 1 bit. 0 = CTRB Peer Address is source of the data, 1 = CTRB Peer Address is the destination

2) Allocation Index : 2 bits (distinguishes up to 4 separate allocations – added to CTA).

3) Async/Isoch Flag : 1 bit, 0 = Async, 1 = Isochronous4) 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.

5) 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.

6) Reserved : 2 bits – for future expansion

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

New CTRB Traffic Addressing

The source and destination traffic address is determined by :

1) 8-bit Source device address in MAC header of Channel Time Request command frame (MAC_SRC_ADR)

2) CTRB Peer device address (CTRB_PEER_ADR)3) CTRB direction flag (CTRB_DIR_FLAG)

If CTRB_DIR_FLAG == 0Traffic is CTRB_PEER_ADR MAC_SRC_ADR

ElseTraffic is MAC_SRC_ADR CTRB_PEER_ADR

Note : This is the same sense as the DSAA “Direction Flag” used in Stream Management.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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).

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission


• 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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission


• “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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission


• 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).

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

July 9, 2001


doc.: IEEE 802.15-01/330r0

Submission

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.

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

Documents

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