September 2010

doc.: IEEE 802.11-10/1112r0

IEEE P802.11
Wireless LANs
CID 487 DTP and Misc Clarifications
Date: 2010-09-13

Author(s):
Name

Affiliation

James Yee

MediaTek

ChaoChun Wang

MediaTek,
USA

Address
No. 1, Dusing 1st Road,
Hsinchu Science Park, Hsinchu,
Taiwan, 30078

Phone
+886-3567-0766

Email
james.yee@mediatek.com
Chaochun.wang@mediatek.co
m

Abstract
Some proposed DTP changes and editorial clarifications supporting CID 487.

Submission

page 1

Carlos Cordeiro, Intel

September 2010
487

All

doc.: IEEE 802.11-10/1112r0

All

All

TR

The spec needs

clarification in several
subclauses. It is much
easier to list them in
separate documents.

Contributions will be
submitted to clarify the
spec.

Proposed Resolution: Accept

Proposed Changes based on: D0.4
Discussion 1:
With DTP (Dynamic Tone Pairing) as described in 9.28, it is possible for there to be unsolicited DTP
Report frames. The ambiguity in whether a DTP Report is in response to a DTP Request needs to be
removed.
Proposed Changes:

9.28 mmWave Dynamic Tone Pairing (DTP)

Make the indicated changes starting with P241L22, the 3rd paragraph of the subclause:
A transmitting STA requests a DTP report from a receiving STA by sending a DTP Request frame to that
STA. Upon receiving a DTP Request frame, the receiving STA shall respond with a DTP Report frame
carrying the DTP configuration. The Dialog Token field of the DTP report is set to the Dialog Token
value in the corresponding DTP Request frame. A receiving STA may also send a DTP Report frame
unsolicited, that is, without receiving a corresponding DTP Request frame.
The transmitting STA should switch to the updated DTP configuration after a DTP Report frame is
received.
If a STA transmits a DTP Report frame in response to the reception of a DTP Request frame, the STA
should not shall not send an updated DTP Report frame unless it receives another DTP Request frame.

The transmitting STA shall indicate the switch from the current configuration to the updated configuration
by toggling the DTP Indicator bit field in the PLCP header. The value of the DTP Indicator field shall be
kept unchanged until the transmitting STA decides to switch to a new DTP configuration. By receiving
ACK frames of data frames from the receiving STA, the switching operation is completed.
Make the editorial correction in subclause 7.4.13.11 DTP Report, P115L21:
TPCDTP Request frame
Discussion 2:
In 7.3.2.30 (P65L26), the allowed Reliability values are:

Submission

page 2

Carlos Cordeiro, Intel

September 2010

doc.: IEEE 802.11-10/1112r0

With only 2 bits and 3 values (assuming not specified = 0 is required), we should select values that are
most useful in actual applications. Is PER the best metric? Do 10E-2 and 10E-5 represent the range of
useful PER, and if so, then is 10E-3 more useful than 10E-2? Assuming one usage scenario is HDMI
video, HDMI requires a BER of 10E-9, so what packet size assumption is used to generate the
corresponding PER? Since 10E-2 PER for large frames is a very low bar for Reliability, we argue that it is
more useful to set the lowest bar to a PER of 10E-3.
Proposed Changes:
Change Table 10 as shown:
Reliability Index
0
1
2
3

PER
Not Specified
10E-3
10E-4
10E-5

Discussion 3:
In 9.23.6.1 Service period (SP) allocation P178L9, the 2nd to last paragraph of the subclause states:
If the STA participates as source STA and/or destination STA in two or more SPs, the PCP STA and
the AP STA should not allocate the SPs separated by less than aMinListeningTime microseconds
between the end of SP in which the STA is either source or destination STA and the start of any SP in
which the STA is either source or destination STA.
We propose an Editorial change by replacing this paragraph with the more succinct:
When scheduling two adjacent SPs, the PCP/AP should allocate the SPs separated by at least
aMinListeningTime microseconds if one or more of the source or destination STA participates in both
SPs.
Discussion 4:
The acronym TDDTT is undefined. The draft also refers to TDMA access as defined in 9.23.6 but
TDMA is not defined in 9.23.6, only time division based channel access in DTT is mentioned.
Proposed Editorial Changes:
Add definition of the TDDTT acronym to Clause 4:
TDDTT
Time Division DTT
7.3.2.91.2 mmWave PCP/AP Capability Information field
The TDDTT field is set to 1 if the STA, while operating as a PCP/AP, is capable of providing TDMA time
division channel access as defined in 9.23.6 and 11.4 and is set to 0 otherwise.
7.3.2.92 mmWave Operation element
The TDDTT field is set to 1 if the PCP/AP provides TDMA time division channel access as defined in
9.23.6 and is set to 0 otherwise.

Submission

page 3

Carlos Cordeiro, Intel