IEEE 802.15 subject

1
Project IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) Submission Title
Bi-Directional CTA Date Submitted July 14,
2004 Source Mark E. Schrader Company
Appairent Technologies Inc. Address 150 Lucius
Gordon Dr., Suite 211, West Henrietta, NY
14586 Voice01-585-214-0584, FAX
01-585-214-2461, E-Mailschrader_at_appairent.com
Tony Tintera Company Appairent Technologies
Inc. Voice01-585-214-0580, FAX
01-585-214-2461, E-Mailtintera_at_appairent.com
George G. She Company Appairent Technologies
Inc. Voice01-585-214-2467, FAX
01-585-214-2461, E-Mailshe_at_appairent.com Re
Abstract CTA with round robin access and
source device provided time slot proprotions for
a pair of devices in an IEEE 802.15.3b
WPAN Purpose For discussion to support
Bi-directional CTA for IEEE 802.15.3b
WPAN 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.
2
Bi-directional CTA

• July 2004

3
Symmetry Problem
The Hall proposal provides the ability for the
destination device to reply within a certain
duration.  However, since the 'grant' of this
ability is currently tied to the transmission of
data by the transmitter, if the transmitter stops
sending data, there is no additional granting of
reverse transmission time to the destination that
may be required to get the transmitter to provide
new data.  As such, the end part of a CTA may
be underutilized in that the transmitter will be
'out' of data, and thus not triggering additional
reverse transmission grants (empty packets, etc)
nor will the destination have capability to
transmit to the sender because it lacks a grant
by the transmitting device.   This proposal
contains a mechanism by which the destination
will be provided transmit opportunities
regardless of source transmissions.
4
Overview

• We propose extending the use of current CTAs to
  support bi-directionality using the Hall proposal
  as the foundation and making several additions.
• The resultant scheme has the following
  properties
• First transmit opportunity by Src DEV
• Second transmit opportunity by Dest DEV
• Alternating opportunities by source and
  destination DEVs for the duration of the CTA.
• Src Dev specifies maximum size for Src DEV time
  slots and Dest DEV time slots within the CTA.

5
Design Criteria

• Different application spaces will require
  different restrictions of the fraction of a CTA
  that the Src DEV and Dest DEV are allowed to
  consume per access.
• Only one of the two devices may have data to send
  during the CTA, or part of the CTA. This should
  be supported to provide good channel utilization,
  low latency, and high throughput.
• A DEV may not have data ready to transmit during
  in a specific access opportunity within the
  CTA, and may have data ready for transmission
  later in the CTA. Access opportunities should be
  maximized to allow devices to transmit when they
  are ready.
• A master-slave relationship between the Src DEV
  and Dest DEV is not appropriate for all
  application spaces.

6
Reversal Methods

• There are two alternative methods
• Implicit reversal based on no transmission and
  CCA if a device does not transmit during its
  access window (TAW) time.
• Token passing transmission to reverse control for
  every access opportunity in the CTA. A device
  either transmits data or it transmits a token to
  hand off the transmit opportunity (more details
  to follow).

7
Definitions for Scenario Slides

• tS A variable amount of time that is less than
  or equal to the amount of time per transmission
  specified by STF. (What the Src DEV needs up to
  the max allowed)
• tD A variable amount of time that is less than
  or equal to the amount of time per transmission
  specified by DTF. (What the Dest DEV needs up to
  the max allowed)
• TCTA The total amount of time in the CTA
  assigned to the Src DEV by the PNC

8
CCA Based Reversal

• 802.15.3 Changes and Transmission Scenarios

9
Dividing Up CTA Time
The source must be able to tell the destination
how much channel time that it can use during its
transmission opportunities. With the CCA method
this is done once in the channel time allocation
request command
10
CCA Based Reversal

• 802.15.3 Changes and Transmission Scenarios

11
Proposed Frame Format Additions

• 7.5.6.1 Channel time request command format add
  1 octet to specify the maximum fraction of the
  allocated channel time that can be used per
  access by the Dest DEV, the value N such that the
  fraction is N / 256.
• Call this 1 octet field the destination time
  fraction (DTF).
• The PNC repeats this value in the response
  command (section 7.5.6.2) and in the CTA status
  IE in the beacon (section 7.10.4) through the
  addition of the DTF field in each of those frame
  formats.
• A DTF value of 0 means Unidirectional time
  slot.

12
Time Fractions

• The addition of the DTF field does not change the
  function of the PNC in allocating channel time.
• The DTF field is used to tell the Dest DEV the
  maximum channel time that it may use for
  transmitting data each time that it is allowed to
  transmit in the CTA.
• The source time fraction is
• STF 1 DTF, the maximum channel time that the
  Src DEV may use for each of its allowed
  transmissions in the CTA.
• The channel time request command can also be used
  to by the source to modify the DTF assignment.

13
CCA Transmission Scenarios
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
Token Passing Based Reversal

• 802.15.3 Changes and Transmission Scenarios

18
Differences from CCA

• No need to modify the channel time request
  command, etc., to include the DTF field
• Instead, a maximum Dest DEV time slot size is
  communicated in a the token sent by the Src DEV,
  which enables the Dest DEV to access to the CTA
• Reversal is based on the presence of a known
  message, not the absence of all messages
• Timing of access windows less critical since it
  is supplemented by the receipt of a message

19
(No Transcript)
20
Source DEV Tokens

• The token sent from the Src DEV to the Dest DEV
  (STK) contains size of the Dest DEVs time slot
  for data transmission
• This allows the Src DEV to control the amount of
  the time that it relinquishes to the Dest DEV on
  a time slot by time slot basis
• This could be useful for some control
  applications such as one in which the Dest DEV
  responds to Srd DEV requests for either status
  information or streaming image data

21
Destination DEV Tokens

• The token sent from the Dest Dev to the Src DEV
  (DTK) does not need any size information
• Therefore there are two possible mechanisms
• A header bit on the last packet in Dest DEVs
  time slot, could be used as the implicit token if
  Src DEV decides how much of the CTA that it will
  use for itself (the usual case)
• A token identical to the Src DEV token could be
  sent by the Dest DEV. This would make the token
  mechanism identical in both directions, enabling
  symmetric bi-directionality
• The next two slides compare the two methods

22
(No Transcript)
23
(No Transcript)
24
Summary and Conclusions
25
Design Alternatives

• Reversal mechanism Access window (CCA)
• Reversal mechanism Token Passing
• Token message from Src to Dest, and implicit
  token from Dest to Src using a header bit.
• Token messages from Src to Dest and Dest to Src
  for fully symmetric operation

26
Summary of Overall Advantages

• Controlled source and destination time slot sizes
  manage access for various applications. Can be
  equal access to very unequal access
• High channel utilization
• Maximum number of transmit opportunities per CTA
• Src DEV still has priority to transmit in the CTA