60 likes | 67 Views
This document presents resolutions to comments related to beamforming in DF02. It provides suggestions and resolutions for improved clarity and interoperability in wireless personal area networks.
E N D
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [DF02 Beamforming Related Comment Resolutions] Date Submitted: [Nov, 2008] Source: [Junyi Wang, Zhou Lan, Chang woo Pyo, Chin-Sean Sum, Tuncer Baykas, Azizur Rahman, Ryuhei Funada, Fumihide Kojima,Hiroshi Harada, Shuzo Kato, Ismail Lakkis +,] Company [National Institute of Information and Communications Technology (NICT), Tensorcom, Samsung ] Address1[3-4 Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847, Japan; 10875 Rancho Bernardo Rd, #108, San Diego, CA 92127+;] Voice1:[+81-46-847-5074] , FAX1: [+81-46-847-5440] E-Mail[junyi.wang@nict.go.jp] Re: [] Abstract: [Comment Resolutions related to Beamforming in DF02] 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.
Comment 149 : This section defines an optional method for devices without any omnidirectional modes to connect to a PNC. If this is left optional it creates interoperability problems for people who purchases only directional devices. • Suggestion from the owner: Remove the optional requirement. • (subclause 8) • Resolution: Accept in principle: Add the sentence to 8.6.6.3 “ A device that is not omni capable on reception and supports multiple receive directions shall implement directional association.”
Comment 213 : There is no clear description on how to use stream index to indicate the allocated CTA for beamforming. • Suggestion from the owner: Define it if necessary or delete the beamforming stream index if it is unnecessary • (subclause 13 Page 153, Line 12) • Resolution: Add a sentence to section 7.5.6.1: At the end of the paragraph that define the stream index. In the case where the DEV is requesting an allocation for beamforming, the n the stream index shall be set to beam forming stream value as described in 7.2.5. Add a sentence to section 8.5.1.1 “If the stream index is set to beam forming stream value then the request is for a CTA for beam forming. If the PNC grants this request, it shall assign the stream index value to beam forming stream index.”
Comment 214: There is no clear definition of "sub-optimal beam-switching criterion" • Suggestion from the owner: Define it if necessary or delete this sentence • (subclause 13.2 Page 156, Line 46) • Resolution: • Replace “sub-optimal beam-switching” with BST
Comment 215: It is clearly defined for AV PHY that LRP mode shall be used for Annouce command transmission, however there is no clear definition for SC and HSI" • Suggestion from the owner: Define it if necessary or delete this sentence • (subclause 13.4.1.1.1 Page 163, Line 4, 13.4.1.1.2 Page 165, Line 51, 13.4.1.2.1Page 169, Line 8, 46) • Resolution: The following sentence shall be inserted into above related positions to indicate the MCS for Announce command transmission. • For the SC and HSI, the feedback IE sent from both DEV1 and DEV2 shall be transmitted using CMS.
Comment 216: "SYNC mode" here is in fact to define the length of training sequences, it is not for synchronization. Use other name to denote it • Suggestion from the owner: change the name • (subclause 13.4.1.1.1 Page 163, Line 27,50, Page 166 Line 21, 44) • Resolution: Suggest to take place of “SYNC mode” by using “Preamble Type”.