1 / 11

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

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment Resolutions for TX switched diversity] Date Submitted: [Sep, 2008]

azriel
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Comment Resolutions for TX switched diversity] Date Submitted: [Sep, 2008] Source: [Chang woo Pyo1, Zhou Lan1, Fumihide Kojima1, Hiroyuki Nakase1, Hirosh Harada1, Shuzo Kato1,Yongsun Kim2, Kyeongpyo Kim2, Seung-Eun Hong2 ,Hyoungjn Kwon2, Wooyong Lee2] Company [NICT1, ETRI2] Address1[NICT , 3-4 Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847, Japan Address2[ETRI, 161 Gajeong-dong, Yuseong-gu, Daejeon, 305-700, Republic of Korea] Voice1:[+81-46-847-5074] , FAX1: [+81-46-847-5440] E-Mail[] Re: [Comment Resolutions for TX switched diversity] Abstract: [Comment Resolutions for TX switched diversity] Purpose:[To be considered in TG3C baseline document.] 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 contributors acknowledge and accept that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

  2. Comment resolutions for TX switched diversity (#23,#57, #536, #560, #581,#582, #583)

  3. High Level Summary • This document provides the resolutions for the comments on TX switched diversity (TSD) • 7 received TSD comments are categorized as following • 3 comments related to TSD protocol (#536, #583,#57) • 3 comment related to receiving channel status (#560 ,#581,#582) • 1 comments related to editorial modification in MLME (#23) • We suggest to • combine the protocol of TSD and BF to complete TSD protocol • modify receiving channel status as LQI (Link Quality Indication) • modify MLME description

  4. Comment resolution related to TSD protocol (1/4) • Comment 536 • Subclause: 8.16.1 • Comment : 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. • SuggestedRemedy: Need clarification • Comment 586 • Subclause: 8.16.1 • Comment: 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. • SuggestedRemedy: What safeguards are in place to ensure that only one side of a link at a time is adjusting its selection? • Comment 57 • Subclause: 8.16.1 • Comment: Missing standard usage of shall, may, should, etc. • SuggestedRemedy: 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.

  5. Comment resolution related to TSD protocol (2/4) • Suggested Resolution • TSD problem • Lacking “communication link set up protocol” between TX-DEV and RX-DEV • Solution of TSD problem • Beam training (Section 13.4) provides “communication link set up protocol” • After setting up communication link by Beam training, TSD protocol can be operated • Suggested solution • TSD protocol (8.16.1) is merged in BF • New subsection (13.7) for TSD is added on the end of BF • TSD IE is modified for the TSD procedure • TSD support (1bit) is added on the DEV capability of Capability IE • 8.16.1 (TSD) is removed and TSD commands(7.5.11) are removed

  6. Comment resolution related to TSD protocol (3/4) • TSD IE (7.4.36) is modified that is transmitted by the announce command • Mode (1octet) • Number of transmit directions (1octet) • indicates the number of TX directions supported by.PNC or DEV • TSD switching request time (1octet) • indicates the time at which DEV shall transmit TSD IE to PNC periodically • Transmit direction index (1octet) • indicates the index of the transmit direction of the PNC Figure 48g—Transmit switched diversity information element format

  7. Comment resolution related to TSD protocol (3/4) • New section for TSD description (13.7) is added on the end of BF • 13.7 Transmit switched diversity • Transmit switched diversity may be used in case that the PNC is capable of multiple directional antennas that are switched one to another and the DEV is capable of the antenna with omni. The TSD capability is indicated in the TSD supported field in Capability IE, as described in 7.4.7. • In case that PNC sends directional beacons, the association procedure of TSD shall follow the directional association as described in 8.6.6.3. During data transmission from PNC to DEV in CTA, TSD may be used. When TSD is used, the DEV shall check the LQI from the data frame and shall compare the LQI with TxDiversityTheshold as described in 6.3.19. If the LQI is lower than TxDiversityTheshold, the DEV shall send the announce command frame to the PNC with TSD IE, which shall set the mode field to 1 and set the transmit direction index field to the next transmit antenna of the PNC. The PNC shall respond to the announce command frame to the DEV with TSD IE, which shall set the mode field to 3 and the transmit direction index field to the corresponding transmit direction of the PNC. The PNC may transmit data frames after switching the transmit direction to the new transmit direction. • The PNC may announce TSD switching request time to the DEV by using the announce command frame with TSD IE which shall set the mode field to 0 and set TSD switching request time field. The DEV shall feedback to the PNC periodically by using the announce command frame according to TSD switching request time whether the current transmit direction of the PNC is changed or not, where the announce command frame includes TSD IE that shall set the mode field to 1 and set the transmit direction index field to the corresponding transmit direction of the PNC. • If the DEV may not know the transmit direction index, the DEV may send the announce command frame with TSD IE to the PNC which shall set the mode field to 2. The PNC shall send the announce command frame with TSD IE to the PNC, which shall set the mode field to 3 and set the transmit direction index filed set to the current antenna index of the PNC.

  8. Comment resolution related to receiving channel status (1/2) • Comment 560 • Subclause 6.3.19 • Comment: What about other possible metrics? • SuggestedRemedy: 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. • Comment 581 • Subclause: 8.16.1 • Comment: 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. • SuggestedRemedy: Perhaps more implementation flexibility is required.

  9. Comment resolution related to receiving channel status (2/2) • Comment 582 • Subclause: 8.16.1 • Comment: 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. • SuggestedRemedy: The comments about SNR should be clearly stated as informative and a more flexible definition with normative text provided. • Suggested Resolution • Accept comment. LQI (link quality indication) is used for receiving channel status • The contents of LQI are left on implementersand are followed by the definition in BF

  10. Comment resolution related to editorial modification in MLME (1/2) • Comment 23 • Subclause: 6.3.19 • Comment: Much of the text in the Transmit Switched Diversity clause seems not appropriate for a section on MLME. • SuggestedRemedy: Parse this section into text suitable for the MLME section and text for either information elements and/or MAC commands.

  11. Comment resolution related to editorial modification in MLME (1/2) • Suggested Resolution • TxDiversityThresholdType is modified • AntennaSwitchingStatus and description in MLME are removed Table 3z—MLME-TXDIV primitive parameters The TXDiversityThreshold is encoded based on the value of TXDiversityThresholdType parameter. The encodings are: — SINR: 0 dB to 30 dB in 1 dB steps. — RSSIR: 0 dB to 30 dB in 1 dB steps. — FER_EXPONENT: The negative of the exponent, from 1 to 10 in 0.25 step size. — BER_EXPONENT: The negative of the BER exponent from 1 to 10 in 0.25 step size. For example, an SINR or RSSIr of 14 dB would be encoded as 14 where as a BER or FER exponent of -3.25 representing 10-3.25 would be encoded as 9 (the negative of the exponent, minus one and multiplied by four).

More Related