doc.: IEEE xxx c Submission July, 2008 ETRISlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolutions to TSD comments] Date Submitted: [] Source: [Seung-Eun Hong 1, Yongsun Kim 2, Kyeongpyo Kim 3, Hyoungjn Kwon 4, Wooyong Lee 5 ] Company: [Electronics and Telecommunications Research Institute (ETRI)] Address: [ETRI, 161 Gajeong-dong, Yuseong-gu, Daejeon, , Republic of Korea] Voice: [], FAX: [], 1, 2, 3, 4, 5 ] Re: [] Abstract: [Comment resolutions.] Purpose: [To be considered in IEEE c standard] Notice: This document has been prepared to assist the IEEE P 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 P

doc.: IEEE xxx c Submission Comment #23 Much of the text in the Transmit Switched Diversity clause seems not appropriate for a section on MLME –Parse this section into text suitable for the MLME section and text for either information elements and/or MAC commands. July, 2008 ETRISlide 2

doc.: IEEE xxx c Submission Proposed Resolution to Comment #23 The transmitter requires only one information from the receiver whether the transmitter switch its transmit antenna or not. And, this information is already included in Transmit diversity request command in subclause Most of the primitive parameters in Table 3z are used between DME and MLME in a single DEV and these parameters are not transferred to the corresponding DEV. Two parameters, TrgtID and OrigID which are unnecessary, will be deleted to keep this text in the position as it is now. July, 2008 ETRISlide 3

doc.: IEEE xxx c Submission Comment #24, #474 and their Resolution Editorial Comment #24 and Comment #474 are the same. Their comments are that subclause number should be –Accepted July, 2008 ETRISlide 4

doc.: IEEE xxx c Submission Comment #57 Missing standard usage of shall, may, should, etc. –This clause is written in an informal manner that is devote of "standard" usage of shall, etc. Please re-write this clause in an appropriate manner. July, 2008 ETRISlide 5

doc.: IEEE xxx c Submission Proposed Resolution to Comment #57 According to the suggested remedy, we will update the related texts. –For details, refer to the resolution to Comment #582. July, 2008 ETRISlide 6

doc.: IEEE xxx c Submission Comment #536 What type of receiver architecture can be supported by the TX switch diversity? There is no mechanism or protocol described how feedback information can be transmitted. –Need clarification July, 2008 ETRISlide 7

doc.: IEEE xxx c Submission Proposed Resolution to Comment #536 July, 2008 ETRISlide 8 TSD does not limit the receiver to a specific architecture. For TSD operation, the receiver uses Transmit switched diversity request command frame to send ‘no-switch’ or ‘switch’ information. –For clarification, we propose to change the related texts in page 55 to the following: –If the received SNR is larger than the threshold, the DEV shall send the Transmit switched diversity request command with ‘no- switch (b7b6=00)’ information to PNC. If the received SNR is smaller than the threshold, the DEV shall send ‘switch (b7b6=1x)’ information to PNC. If the SNR for all transmit antennas are less than the predetermined threshold, DEV shall send the index of the transmit antenna with the largest received SNR.

doc.: IEEE xxx c Submission Comment #558 and its Resolution Editorial "TXDiversityThresholdType" should be "TxDiversityThresholdType" for consistency. –Accepted as suggested. July, 2008 ETRISlide 9

doc.: IEEE xxx c Submission Comment #559 What happens when a value (e.g., SINR) is outside the specified range? –Specify whether values are saturated or whether an invalid code is sent for out-of-range values. July, 2008 ETRISlide 10

doc.: IEEE xxx c Submission Proposed Resolution to Comment #559 Valid range, 0 ~ 255, of TxDiversityThreshold in Table 3z should be replaced with “separately addressed according to the TxDiversityThresholdType (refer to the below)”. –SINR: 0 dB to 28 dB in 1 dB steps (valid range: 0 ~ 28). –RSSIr: 0 dB to 28 dB in 1 dB steps (valid range: 0 ~ 28). –FER_EXPONENT: The negative of the exponent, from 1 to 10 in 0.25 step size (valid range: 0 ~ 40). –BER_EXPONENT: The negative of the BER exponent from 1 to 10 in 0.25 step size (valid range: 0 ~ 40). The valid ranges of SINR and RSSIr are modified to be consistent with the SINR field and RSSIr field of the Received status field format in Add the following text after the last paragraph in : –If the TxDiversityThreshold value is out-of-range, the MLME- TXDIV.request is immediately rejected and MLME- TXDIV.confirm with ResultCode=FAILURE and ReasonCode=OTHER is issued. July, 2008 ETRISlide 11

doc.: IEEE xxx c Submission Comment #560 What about other possible metrics? –For example, one could use a calculated capacity value, some sort of signal quality metric which is a function of LLRs, etc. Perhaps a more flexible or inclusive definition is required. July, 2008 ETRISlide 12

doc.: IEEE xxx c Submission Proposed Resolution to Comment #560 There are numerous metrics which can decide the channel status or data reliability. It is difficult to list all the possible metrics in the document and it is also uncomfortable to list some well-known major metrics. Substitute current four TxDiversityThresholdType with “USER_SPECIFIC_METRIC” in table 3z and also leave the valid range of TxDiversityThreshold to the implementers within the range of This parameter is one of MLME primitive parameters and MLME primitive parameters are not transmitted to the other device which means there is no interoperability problem between devices from different vendors. Accordingly, resolution to Comment #559 has to be modified, especially, the valid range part. July, 2008 ETRISlide 13

doc.: IEEE xxx c Submission Comment #580 "The process is performed in CAP by using the base rate." What is meant by the "process"? If "process" means the procedure by which an antenna is selected, why must that procedure occur in the CAP? What is the "base rate" and why must it be used? –Please clarify. Also, the restriction that the procedure must be executed in the CAP seems excessively restrictive. July, 2008 ETRISlide 14

doc.: IEEE xxx c Submission Proposed Resolution to Comment #580 We propose that the sentence “The process is performed in CAP by using the base rate” should be removed July, 2008 ETRISlide 15

doc.: IEEE xxx c Submission Comment #581 Figure 147c indicates that the feedback is an "Antenna Switching Indicator". Why must the antenna selection be made at the receiving end? The receiver could feedback SNR, SINR, BER, etc. information and allow the decision to be made on the transmitting end. –Perhaps more implementation flexibility is required. July, 2008 ETRISlide 16

doc.: IEEE xxx c Submission Proposed Resolution to Comment #581 The TSD currently put an emphasis on simplicity rather than optimization However, we will update the related text to give more flexibility for the implementation as recommended. We propose that we leave this comment open for discussion until September. July, 2008 ETRISlide 17

doc.: IEEE xxx c Submission Comment #582 The text states that received SNR is compared against a predetermined threshold. First of all, there is no truly normative ("SHALL") text. Second, why must SNR be used? In some cases, it may be impossible to get a good estimate of the true SNR. It may be easier to compare RSSI or perhaps better results could be obtained with a BER or capacity or SINR estimate. –The comments about SNR should be clearly stated as informative and a more flexible definition with normative text provided. July, 2008 ETRISlide 18

doc.: IEEE xxx c Submission Proposed Resolution to Comment #582 The resolution to the first part of the comment is in the next slide. Further polishing will be done. For the second part of the comment, it is related with Comment #560. So, we propose that SNR should be replaced with “a predetermined metric.” July, 2008 ETRISlide 19

doc.: IEEE xxx c Submission Proposed Resolution to Comment #57 and #582 (Cont’d) Transmit switched diversity is used to achieve diversity gain from shadowing or blockage. The process is performed in CAP by using the base rate. To perform transmit switched diversity, the PNC shall have multiple antennas that share one common RF chain, as illustrated in Figure 147c. The PNC shall first inform the DEV of the number of transmit antennas. In the first transmission, the PNC shall arbitrarily select one antenna from multiple transmit antennas. When the DEV receives a packet from the PNC, the DEV should check the predetermined metric and compares it to a predetermined threshold. According to the relationship between the predetermined metric and the threshold, the DEV shall send an MLME-TXDIV.request to the MAC/MLME. Then, DEV shall send the Transmit Switched Diversity Request command, as described in , to the PNC. If the predetermined metric is larger than the threshold, the DEV shall send ‘no-switch (b7b6=00)’ information to PNC. If the predetermined metric is smaller than the threshold, the DEV shall send ‘switch (b7b6=1x)’ information to PNC. If the predetermined metric for all transmit antennas are less than the predetermined threshold, DEV shall send the index of the transmit antenna with the best predetermined metric. According to the information in the command frame, the PNC shall perform the switching operation. PNC shall then send Transmit Switched Diversity Response command as defined in , containing the switching results to DEV. After that, PNC MAC/MLME shall send MLME- TXDIV.indication including antenna index information to PNC DME. The originating DEV after receiving Transmit Switched Diversity Response command shall terminate transmit switched diversity process according to the result. Figure 147d illustrates the message sequence for transmit switched diversity request process.

doc.: IEEE xxx c Submission Comment #583 How does the transmit diversity procedure stabilize in the case that that both sides of the link may attempt to select transmitter/receiver antennas? If the PNC has selected one of K possible antennas for communication with a DEV and the DEV selects one of N possible antennas for communication with the PNC, then the PNC switches its selected antenna, the selected antenna at the DEV may no longer be the best choice. –What safeguards are in place to ensure that only one side of a link at a time is adjusting its selection? July, 2008 ETRISlide 21

doc.: IEEE xxx c Submission Proposed Resolution to Comment #583 According to the current TSD operation, PNC does not switch its antenna without the indication of the receiver. When implementing the receiver, for a given PNC antenna, the receiver may first select the best receiver antenna, and then the receiver may command to switch the current PNC antenna to the other. PNC switches its antenna only when Transmit switched diversity request command, which is defined in , from the receiver. The text in includes the following sentence: “According to the information in the command frame, the PNC shall perform the switching operation.” July, 2008 ETRISlide 22