11-10-1112-00-00ad-cid487-dtp-and-misc-clarifications.doc

4
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 Affiliatio n Address Phone Email James Yee MediaTek No. 1, Dusing 1st Road, Hsinchu Science Park, Hsinchu, Taiwan, 30078 +886-3- 567- 0766 [email protected] m ChaoChun Wang MediaTek, USA Chaochun.wang@mediate k.com Submission page 1 Carlos Cordeiro, Intel Abstract Some proposed DTP changes and editorial clarifications supporting CID 487.

Upload: harjinder-singh

Post on 18-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

doc.: IEEE 802.11-10/1112r0

September 2010

doc.: IEEE 802.11-10/1112r0

IEEE P802.11Wireless LANs

CID 487 DTP and Misc Clarifications

Date: 2010-09-13

Author(s):

NameAffiliationAddressPhoneEmail

James YeeMediaTekNo. 1, Dusing 1st Road, Hsinchu Science Park, Hsinchu, Taiwan, [email protected]

ChaoChun WangMediaTek, [email protected]

487AllAllAllTRThe 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.4Discussion 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:

.

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 IndexPER

0Not Specified

110E-3

210E-4

310E-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:

TDDTTTime Division DTT

7.3.2.91.2 mmWave PCP/AP Capability Information fieldThe 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.

Abstract

Some proposed DTP changes and editorial clarifications supporting CID 487.

Submissionpage 3Carlos Cordeiro, Intel